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.
Related
Hope you are having a nice day.
My issue is related to a NMEA node not acting properly when I send it GPS information received from an Arduino or Inject function.
It is being sent via serial and has supposedly the correct format.
I tried the same using a VK-162 (USB GPS) and it is working well.
But when I try to send a message with a format like:
$GPGLL,4916.45,N,12311.12,W,225444,A
or with the Arduino, I get the following in my debug area:
If someone could give me some insight I would greatly appreciate it :)
All the best.
It looks like you are missing a checksum from the end of the line
All of the following work
$GPGLL,4916.45,N,12311.12,W,225444,A*31
$GPGLL,5133.81,N,00042.25,W*75
$GPGLL,3751.65,S,14507.36,E*77
(checksum calculated with https://nmeachecksum.eqth.net/)
Hey there trusty SO community,
I'm working on a project for my new Samsung "The Frame" TV using a IR remote controller. I am trying to send a "repeating" command (when a button is held continuously). I have no problem sending single commands, I am able to control almost everything I need at this point.
Unfortunately, sending the "power" code on the Samsung Frame TV simply selects the "art" mode. Using the original RF remote, the power button has the same action: "art" mode vs TV mode. In order to turn off the TV with the original RF remote, one has to hold down the power button for a second or two.
So I assume that the IR remote interface would be the same.
I have tried sending all sorts of commands (left arrow, right arrow, volume+, etc...) in repeat mode, but the TV only ever responds to the first command and ignores the "repeat" signals. To be clear, the repeat code blocks are being sent, but for some reason ignored. I was able to validate the repeats are sent correctly using a separate sender and receiver.
I have a working prototype of a custom remote that uses this arduino library
I have also read through this SO thread which is incredibly helpful in understanding the protocol.
I wasn't able to find exact information on the protocol of a repeat command, perhaps there is a bug in the library?
line of code that works for single commands:
IrSender.sendSamsung(0x0707, 0x02, 0); //address, command=pwr, number of repeats = 0
line of code that sends the repeat code
IrSender.sendSamsung(0x0707, 0x02, 10); //address, command=pwr, number of repeats = 10
Thanks in advance,
It turns out that version 3.7.1 and earlier of Arduino-IRremote library implements a "special" repeat handling message. After comparing the repeat protocol to a Samsung Brand remote control, it was found that the repeat messages are actually identical to the single message.
An update was made to Arduino-IRremote in this ticket to fix the Samsung repeat messages.
A release has not yet been created as of typing this, but assume version 3.7.2 or greater will support Samsung correctly.
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!
I'm working on a basic sketch for an Adafruit Huzzah which uses the Adafruit IO MQTT library. This is put together by copy/pasting from various sources and examples, and mostly works - but there's one thing I can't figure out.
Right now, I'm using a line of code which fires off a handler every time a new message is received via the feed I'm subscribed to:
group->onMessage("daniel", handleMessage);
This is fine, and does what I need it to do for values which are updated.
What I want to do, however, is grab the last known value on the feed during the setup() routine, rather than having to wait for a new value to come though.
In MQTT parlance, I believe this is known as retained messages, which I think Adafruit IO has on by default, but I don't know how to grab these values during the startup() process.
Can anyone help me out?
(If you're interested, here's my code so far: https://github.com/LimeBlast/family-box/blob/master/family-box.ino)
Short answer is you don't... do anything.
Retained messages are delivered just the same as normal messages (via the onMessage callback), they are just delivered as soon as you subscribe to the topic.
I also had this problem. Here is the full explination
The get() function wil ask the Adafruit servers to resend the last value of the feed to this client only. When the value is received, the handler will be executed.
exampleFeed->get();
Seeing as I've just found the answer to the question I was asking, I figured it only right I post it here.
The command I was looking for, after having setup the feed, was ->get(), as shown in this example.
I am receiving messages from a CAN interface into my mBed device. The mBed device then parses the information to send out on serial to another device. The information is sent out in the following format.
"< msg>xxxxxxxxxxxxxxxxxxx< /msg>" where x = a hex number.
The other device receiving this message will receive the information split up in half (i've accounted for this in the code). The problem I'm having is, the messages will fall into the format ..... but there are times where the format is lost, for example:
[1]xxxx< /msg>< msg>xxxxx
[2]xxxxxxxx< msg>xxxxxxx
[3]< /msg>< msg>xxxxxxxxx
[4]xxx< /msg>< msg>xxxxxx
**Please ignore the space in the msg tag, it was necessary to show on StackOverflow'**
The baud rate set 38400bps on the mBed. I'm not using any parity, stop bit, start bit etc as I'm not too familiar with how they work. Can anyone help me how I might fix this loss in format, or am I going to have to include code in the receiving device to handle this?
Many thanks in advance!
This is entirely normal, serial ports are not smart enough to recognize XML. You will have to write the code yourself. A basic algorithm is a state machine. Declare a buffer that's large enough to store a complete message. Then:
throw everything away you receive until you get '<'
store bytes you receive in the buffer until you get '>'
check that you got <msg>, back to state 1 if you did not
store bytes you receive in the buffer until you get '>'
check that you got <msg/>, back to state 1 if you did not
process the message, back to state 1
This ensures that you'll properly sync with the bus when you open the port and that you don't care how many bytes you receive in one read() call.