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/)
Related
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 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 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'm trying to read temperature data from BMP180 using my BLE112 via I2C. The problem is that what get in the very end are some unrelevant numbers. I think i am missing something extremely important. I follow BMP180 datasheet point by point. Program that i have is wrote in BGScript from Bluegiga
There are few things that are strange in my opinion:
measuring raw temperature (even though is not correct) sometimes gives 0.. So how slow is this programmable I2C?
http://www.sureshjoshi.com/embedded/ble112-how-to-use-i2c/ Suresh Joshi writes here that register i should write and read in is the one from datasheet left shifted once. Is it necessary also in my case?
can someone verify these staps of algorithm:
a) reading calibrations: call hardware_i2c_read(238,0,"\xaa")(result,data_len,sensor(0:22)) - should i write something before?
b) write 0x2E into reg 0xF4 should it be : call hardware_i2c_write(238,1,2,"\xf4\x2e")(written) ?
c) read reg 0xF6(MSB) and 0xF7(LSB) should it be call hardware_i2c_read(239,0,"\xf6")(result,data_len, MSB) and call hardware_i2c_read(239,0,"\xf7")(result,data_len,LSB)
I am struggling so hard so if anyone could tell me what is wrong or if i can't use this sensor with this BLE module please tell me! (:
My .bgs file : http://pastebin.com/3zHVdNrT
BR Bartek
I am using the TinyGPS library and am trying to display information to get to a specific latitude/longitude via an LCD screen.
I am not getting any data. The output of directionto is "broke" and distanceto and bearingto is 0.
Code redacted
And here is what my pins/hardware look like: http://i.imgur.com/7iDBwxm.jpg
I am using an Arduino Uno, LCD shield and GPS shield by ITead Studio.
I am hoping it is either the pins or not having a GPS signal.
Reddit post: Arduino TinyGPS help
The baud rate for SoftSerial should be 9600.
You need to debug the system step by step to understand where the problem is.
I would start using only the serial monitor and no display.
Please note that when you switch on a GPS that has been moved for several hundred km, and the same is when you switch it on for the first time, may take a while to get the satellites and start giving out some data. Make sure you are in a open area and wait for 5 to 10 minutes before you declare it as "not working". The next time you will switch it on will be much quicker.
I have checked the documentation of your shield and what they also say is to make sure the Micro SD card you use is support SPI mode but not just the SD mode, also don’t forget to format it into FAT16 , and add a “datalog.txt” file on your card for Arduino to log the information.
Try that and then read the data on the sd card to make sure that is logging.
Come back with the outcome of the above tests and we will try to support you further.