I am using the HM-18 modules by DSD tech, and I pushed the following code in:
https://github.com/dinosd/BLE_PROXIMITY
The HM-18 slaves are very similar to the HM-10s, so it should work theoretically. I went through all the code and libraries to see if there were any specs I'd need to change but there doesn't seem to be anything specific to the HM-10s in there that I'd need to adjust.
However, this is all my serial monitor outputs:
OK
OK+Set:1
OK+Set:1
OK+RESET
No device
There are a couple of active beacons near the slave, so it should be able to detect them - my phone can detect them no problem. Does anyone know what could be changed so I can read these beacons?
Any tips would be very appreciated!
Related
I currently have firmware that can reach an average deep sleep current of ~130uA. I can reach this level reproducibly on one of the boards I have.
successful deep sleep
Trouble is, when I try to clone this chip onto other chips using the nRF Programmer (Connect) app, I get extremely high power consumption, average of ~20mA at all times, seems the device doesn't reach deep sleep properly. Tried this on several other boards, so I don't believe it's simply a problem of something shorting. Strangely, the application just runs fine, the current is just several times normal for the same functionality.
unsuccessful deep sleep
Does anyone have any ideas on how I can truly clone the flash of one device, onto another? Clearly the "save as file" on nRF Connect isn't doing this. Erasing all and reuploading, starting from a blank chip and writing,
FYI I'm using the nRF52840 module by Raytac (MDBT50Q), implemented on a custom board. This board SHOULD be capable of going down to ~33uA, which I have observed in the past with this very board. By some combination of erasing all, reprogramming, setting the 3.3V logic level(nrfjprog --memwr 0x10001304 --val 5), etc,
For posterity, I did actually find the solution! For anyone else in a similar boat to me, the winning command is:
nrfjprog.exe --readcode --readuicr --readram [filename.hex]
Apparently, the --readram was the winning flag, as without it the sketch simply doesn't run at the same current consumption for whatever reason. But now, I can reproducibly image and transfer identical firmware, which was what I was after.
I am a bit new here, English is not my native, so I am sorry for any possible misspelling.
I have a very odd problem - my Xiaomi Mi Surface Display 34" (XMMNTWQ34 model) monitor buttons act really strange - instead of calling the monitor OSD, pressing any of 4 present buttons tries to switch to another possible input source (this is even not their function!), but no luck: just 3 seconds of the black screen and it turns back to the initial image. Let me explain how I got into this.
I have a monitor named before, which has 4 input ports: 2 DP and 2 HDMI. There is a PC always connected to the monitor via the DP interface (DP1 to be exact). Today I tried to connect a second PC via HDMI to the HDMI1 port. It went totally good, I was able to switch between PCs using a monitor OSD. But I thought it was too long and complicated to press a dozen buttons on OSD just to change an input source, so started to google any other programmatical methods of doing such thing.
Some fact: there are no drivers for this monitor on the Internet (it actually works at full 3440x1440#144 Hz resolution/refresh rate via DP interface without any trouble, but Windows sees it as "Generic PnP Monitor", so I see no way to fix it without a relevant driver).
I have found that any VESA-compatible monitor has the 0x60 parameter, which means exactly "input source", so altering the value of this parameter switches the input source without the need to call an OSD. I have found that the possible values of this 0x60 parameter for my monitor provided by several utilities are: 0x0F, 0x10, 0x11, and 0x12. But setting any of these values got me no luck - the screen just flashed black and nothing more. Moreover, those utilities showed that the current value of the 0x60 parameter was 0x07 - described as "S-Video 1" input source, and it did not change at any made tries. But my monitor does not even have such input ports!
But I discovered a total disaster a bit later - when I tried to switch the input source via OSD, I was not able to call it - any of the 4 buttons on the monitor was causing a black flash and nothing more! So OSD is now totally unavailable! This is madness. I can't enter the OSD, I can't change the input source without turning off any one of 2 connected PCs, I can't do anything which is supposed to be made via OSD. Rebooting and reattaching of every possible thing has no effect - even with 2 PCs being connected to monitor and waiting to enter a BIOS password (no OS loaded whatsoever): pressing any button on the monitor causes only black flash and nothing more, no OSD called. I guess this is a strictly monitor firmware issue because the OSD worked well until yesterday.
I have absolutely no idea how to solve this, I googled this all day long, but no luck. System restore did not change anything. Please help. Thank you all very much.
Same issue after using ControlMyMonitor App. At the time being, i didn't found any solution to get the OSD back. And I didn't found any solution to factory reset the monitor, I don't know if it's possible.
I strongly discourage users to use any kind of VESA com application on this Xiaomi 34 monitor !
Now, the best solution in order to switch inputs, is to disconnect or shutdown one of the computer connected, ans it will switch automaticaly to the only one remaining. (Or use a VESA script...)
I am trying to make the Nano33SenseReceive example of the ChirpSDK 3.4.0 work on a newly bought Arduino Nano 33 BLE Sense.
I have added my credentials to the credentials.h file and uploaded the sketch to the board. I am playing the sounds from the vimeo videos embedded in this Arduino Project Hub page using my laptop speakers but nothing gets printed on the serial monitor and the LED does not turn on.
To test if the sketch starts, I added a line:
Serial.println("Serial started.");
just after the:
while (!Serial);
and it prints the line just fine, once I open the serial monitor, so it seems the sketch is running properly. This, however, is the only thing I get on the monitor, no matter how many times I play the sounds.
Any ideas what could be going wrong?
(Edited after responses by Dinu and joerobot)
I have managed to make it listen by using 16khz-mono-embedded. However, although the code now hears the sound, it fails to parse it. Here is example output from the monitor:
Chirp SDK initialised.
Receiving data...
Received data: ⸮
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data:
Receiving data...
Received data: ⸮
Receiving data...
Received data: ⸮
On the plus side, I had absolutely no idea a left-to-right flipped question mark existed so can't complain much. On the minus side it's a bit disappointing to see that the mic can't figure out a chirp at a few centimeters from the speaker in a quiet room. Having said that, it's still early days so I 'm hoping future version of the SDK will iron out performance issues.
(Edited to add hardware details)
I have tried two laptops, one Clevo with Onkyo speakers and an Intel sound card and one Lenovo X1.
I have also tried my phone, Lenovo K33a48.
In all cases, I uploaded a fresh copy of the example file in File > Examples > ChirpSDK > Nano33SenseReceive and played the vimeo videos embedded in this page at full volume, right next to the Arduino. Here is a direct vimeo link to one of the videos.
Every time, I get theReceiving data... message, showing that the transmission is understood as such but then I get the empty Received data:, occasionally with the left to right question mark.
The config string from the credentials.h correspond to a specific protocol. Make sure your app on the developer's website is set with the correct protocol , which is 16khz mono in the video if I'm not wrong.
As Joe mentioned, 16khz-mono-embedded needs to be used for Arduino
I had this issue too - turns out the problem isn't in the receiver at all, but in the data being sent.
For whatever reason, the videos that you linked that should be sending RGB values just seem to give the backwards ?.
If you use messenger.chirp.io to generate sounds then the message will be displayed correctly in the serial monitor.
I'm quite new to working with Arduino/GSM and have had problems getting basic HTTP functionality working. I am currently facing multiple problems - one being that the 3G shield I am working with (SIMCOM SIM5216A) does not seem to want to connect to a carrier! :(
However, the problem I would like to focus on for this question is that Phone Functionality - designated through the AT+CFUN command - does not seem to be maintained through power cycles. Additionally, sometimes after modifying the CFUN, the modem will run a soft reset.
Here is the command I have been using to modify the phone functionality of the modem:
AT+CFUN=1,0
I am under the impression that the second parameter should stop it from running a soft reset.
I have attempted to save the AT configuration by following advice in this question's accepted answer - here is the output from power on:
START
+STIN: 25
+STIN: 25
+CPIN: READY
SMS DONE
PB DONE
AT+CFUN=1,0
OK
AT&W
OK
However, whenever I next reset, I will get the following:
AT+CFUN?
+CFUN: 4
OK
So, my question is how can I save the CFUN configuration to be consistent between power cycles? (If you happen to be able to offer advice on why I can see medium-strength signal but cannot connect to an operator network, any advice would be welcome there too, however that is not the focus of this question)
With thanks,
BadDevH.
Exactly what that is saved with AT&W is a rather muddled, see this answer for details. However, regardless of that, the AT+CFUN command is controlling such a dynamic behaviour that I cannot imagine any manufacturer ever that has saved this with &W. Think more of CFUN more like setting a fixed cruise control speed while driving a car. There is no way the car will continue with the speed from last time when started.
For normal phones the default behaviour is value 1 - full functionality - because that is the very core functionality of what they do1, but for a GSM module shield, I am guessing that the default behaviour is set to no radio in order to save power, so it stays off until you need it at which point you need to explicitly turn it on.
1
And even in the case of no sim card present, it shall still be able to make emergency calls.
I have a DirectShow webcam application. I make use of Sample Grabber to get the buffer callbacks and IVideoWindow to control the display co-ordinates for the Preview. I have Preview and Capture Streams which I run as below.
g_pBuild->RenderStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video,cam,g_pGrabberF,pNullRenderer2); g_pBuild->RenderStream(&PIN_CATEGORY_PREVIEW, &MEDIATYPE_Video,cam,NULL,NULL);
On certain On board cameras, IMediaControl::Run followed by IMediaControl::Stop followed by IMediaCOntrol::Run doesn't switch on the camera.
Extenal USB cameras work properly here. How can I diagnose more on this? Any pointers, please help.
Maybe its specific to a certain hardware issue in the unit.
Do a quick test by adding sleep of 1 sec between calls.
If it does help than you need to find a way to know when to unit state in idle or not.
There are two important parts of the question which you did not provide:
Filter graph topologies
HRESULTs of the method calls
A problem you might be having is that one of the filters in the topology does not handle well state transitions and fails somewhere between states. Supposedly your second Run meets it still trying to complete Stop. You might get a HRESULT there which indicates the issue (better for you) or the filter fails silently.
The filter graph's is the unlikely source of the bug itself. Chances are high that it does everything flawlessly, however since internally it distributes the calls between filters, one of the filter is letting you down.