Not an issue, but questions about the decoding and trackers.

[EdgarBarranco]

I found your code, thank you for making it public. I loaded it to a NodeMCU and connected it to an Adafruit breakout board. I made a little perf breadboard: http://imgur.com/a/H5fBQ It seems to be working fine.

I am having a little issue on the target side of things and I am not sure if it is related to the gateway or not. Maybe you can give me some pointers if you don’t mind.

For the tracker hardware I am using an arduino + adafruit ultimate data logger shield and the dragino Lora shield. I know that I need to move CS on the lora board to other pin to avoid conflicts with the SD card, but I will do that later. I don’t think the problem is related to that, plus there is no SD card inserted at the moment.

At first I started using the RH_RF95 library. With that library I made the code listed here: https://pastebin.com/wtksK3vA
The problem I am experiencing with this code is that the gateway prints out 2424 5445 5354 2C38… so it does receives $$TEST but for some reason it doesn’t detects the $$ . I saw where this check is done: if (rf95.headerTo() == '$' && rf95.headerFrom() == '$' ) { but it never goes down that if statement. I have tried different things, but nothing seems to correct this.

I decided to try a different library and used the lora library from sandeepmistry https://github.com/sandeepmistry/arduino-LoRa
Using that library I made this code:
https://pastebin.com/wkbB4Ugr
With this code I do get correct sentences decoded by the gateway, but for some reason I can only decode if spreading factor is 7, anything else and gateway ignores it. With the code using RH_RF95 I can select all the rates, the gateway sees them, but the sentences are never decoded correctly.

On both codes I am verifying that the configuration registers match. If you have any inputs on what could be causing the decoding issues with my code using the RH_RF95 library, the spreading factor issues with the Sandeepmistry library or better yet sample code for trakers used with this gateway, I would appreciate it.

At the end I will be using feather boards from adafruit, but I am working with the arduino just because it is a bit more flexible.

Thank you for your help and making this code available to others.

[torntrousers]

Hi kc2uez. I suspect the issue is that I've hacked a little to use the RH_RF95 library. The Radiohead library is designed to use addressed packets. If you look in RH_RF95.cpp in rf95Send you see it sets the start bytes of a packet to _txHeaderTo, _txHeaderFrom, _txHeaderId, _txHeaderFlags. In my tracker code (that I see now I've never put up in Github) I've copied that rf95Send function and commented out the sending of those header bytes, and that is why in the Gateway code when it receives a message its getting the start bytes with (rf95.headerTo() == '$' && rf95.headerFrom() == '$' ).
Its a bit imperfect. I was trying to make this compatible with the other existing Lora tracker and gateway code that people use so didn't want the addressing bytes to get set, but also I didn't want to have to write all the low level code for using the radio modules so wanted an existing library for that and the only one around seems to be the Radiohead one, but I couldn't see anyway to have it not use those header bytes.

[EdgarBarranco]

Hi torntrousers, thank you for your feedback. I understand now why my code is not working. Trying to figure out why I was getting the HEX values, made me become very familiar with the send function I just never thought about copying and modifying it. I was thinking that I was doing something wrong and it was the reason I decided to try out the second library.
I have been trying also the RPI gateway from PITS, but I couldn't get it to work. Back then I was only using the RH_RF95 lib and kept getting CRC errors, now that I think about this, it could be related to the to the header situation. If you don't mind, could you please make available the tracker part of the code, I would appreciate it. I am ham volunteering to help the local high school with their HABs and electronics. Having something to use as a guide would save us a lot of time. Thanks!

[EdgarBarranco]

Just as a follow up, I commented out of rh_rf95.cpp
// spiWrite(RH_RF95_REG_00_FIFO, _txHeaderTo);
// spiWrite(RH_RF95_REG_00_FIFO, _txHeaderFrom);
// spiWrite(RH_RF95_REG_00_FIFO, _txHeaderId);
// spiWrite(RH_RF95_REG_00_FIFO, _txHeaderFlags);
and that fixed the problem I was getting! Thank you for pointing me on the right direction.

[torntrousers]

Great! I need to hunt around for the tracker code, will try to do that later tonight.

[EdgarBarranco]

Hi torntrousers, I have another question. I have generated a payload on habitat, but the esp8266 page shows 500 on the habitat column. Do I need to do something special or as long as my payload matches, it should be showing on their debug console?
Thanks..

[torntrousers]

500 is a generic error so not so helpful, does the habitat log show any more? Go here and watch as your message is sent - http://habitat.habhub.org/logtail/

(sorry have been busy so still not put up the tracker code)

[torntrousers]

(I think from what I remember even if the payload doesn't match there will still be a log message appearing in the habhub log saying its got an unknown msg)

[EdgarBarranco]

Hi torntrousers, I got it to work. There are 2 fixes needed if you care to implement them on the master.

1. String b64Sentence = base64::encode(sentence);
   The encode for the esp8266 base64.h seems to add either \n or \r every 76 characters.
   Adding:
   b64Sentence.replace("\n","");
   b64Sentence.replace("\r","");
   Corrects that problem.

2. After that habitat returned 403.. It was odd that the logtail only reported that there was an error on the data and was not valid. I found an extension of firefox called httprequester and with that I sent the same json put and saw that the date was not formatted correctly due to the month. I guess habitat didn't like that march is a single digit month. I saw where on getRFC3339Time() the monthInt was being set, I changed it to a string and added "01", "02".. Now it works.

Thank you for your help!

[torntrousers]

Thats terrific, well done. Would you share your fixes?

[torntrousers]

(Some tracker code here: https://github.com/HarringayMakerSpace/HAB/tree/master/HABTracker)