New features for the project

[aviateur17]

Timm, wondering what features you are looking forward to introducing to the project and what you're looking for help on? Are there any unfinished features that you're looking to complete? If you're open to assistance I'd love to help but I don't have a ton of time to spend.

Thanks!

[timmbogner]

Hey Jeff,
Much appreciated! Are you interested in LoRa-related things, or other stuff?

• LoRa channel activity detection is a (hopefully) small thing that I have pegged to do.
• A medium-sized thing would be making system packet functionality (mostly ping) available to LoRa.
• There will also be the larger final task of LoRa controller functionality, but probably not quite ready for that yet.

Non-LoRa there are a couple things:

• Most interesting in my opinion would be adding UART input and output as options for nodes. This way, an ESP microcontroller with sensors attached could be physically attached to a gateway and send readings via serial, with the gateway accepting them through existing serial in and out capabilities.
• I'm also looking to expand the examples with different examples of concepts, especially for controllers and specific sensors. If you have experience with coding for motors and actuators, that's definitely something I need help with.

I'll keep thinking over the next few days. If one of these pops out at you let me know and I'll give you more details.
Thanks again!

[timmbogner]

A fun thing that I just remembered is the ESP32 LR mode. I never added it in the interest of keeping ESP8266 compatibility. But now the user could either "USE_LR" on the entire system if they don't use 8266, or set up a UART gateway between the LR-mode portion and the normal-mode devices.
Any interest in tackling that? Thinking about it, it's probably pretty simple. I think LR is just enabled in setup. The research and testing are mainly why I keep putting it off. The advantages should be huge for anyone not using 8266, though.

[timmbogner]

I also just added "internal timekeeping" to the future plans list. This is something I've been considering for a while. While I'm hesitant to add a lot of extra features and addons to the basic internal workings of FDRS, there are so many benefits to this one that I think it is worth adding the fluff. Besides opening up the system to battery-powered clock projects and such, timekeeping will provide context for datapoints which should also open up @thefeiter's SD card functionality to actual logging.

This is something that I'll make an issue to discuss in the future. I want this to be available to LoRa, which will require LoRa system packets and a conversation about the mechanics of it. I'm considering using ESP-NOW broadcast packets somehow. The main thing is that it should only need timekeeping configuration on the device with NTP or RTC, with the rest just effortlessly distributing it.

I just wanted to bring this to you and @thefeiter's attention so you guys can think on it if you want.

[timmbogner]

Hey @aviateur17,
First off, I apologize as I'd forgotten that LoRa ping was already included. I also forgot that LoRa confirmation on gateways is displayed but there aren't retry attempts implemented. I've been looking at the method used in the sensors, and the first modification I think it would need for gateways would be keep it from blocking out other tasks while waiting for the confirmation packet.
I have new LoRa modules arriving very soon and am hoping to start working on that side of things when they do. If you do have time to work on this it would be great, but it's no biggie if you're too busy. After that it will time to bring two-way-comms to LoRa, which I'd also love your input on:

My thought is for gateways to implement broadcast packets, and nodes will simply listen for broadcast packets specifically from their gateway, and subscribe to DataReading IDs like on ESP-NOW.
My idea, which may not be a very good one, is that IF a node wants to confirm that it is getting all of the gateway's packets, it can register with the gateway. This will trigger a similar registration system to ESP-NOW. After it is registered, the gateway will expect an ACK from the node every time it sends out a packet, and will retry if not acknowledged. Could get messy, and would need to stagger the ACKs for multiple nodes somehow. What do you think?

[timmbogner]

Yep, gotcha.

Gateway is the 1_UART_Gateway sketch with USE_LORA enabled, but otherwise unchanged. Sensor is the LoRa_Sensor sketch.

Gateway:

08:33:31.806 -> Incoming LoRa. Size: 20 Bytes, RSSI: -58dBm, SNR: 10.00dB, PacketCRC: 0xbc00, Total LoRa received: 4, CRC Ok Pct 100.00%
08:33:31.806 -> CRC Match, sending ACK packet to sensor 0xeb50(hex)
08:33:31.806 -> Transmitting LoRa message of size 11 bytes with CRC 0xffea to LoRa MAC 0xeb50
08:33:31.880 -> Sending Serial.
08:33:31.880 -> [{"id":2,"type":3,"data":49},{"id":2,"type":1,"data":21}]
08:33:31.912 -> Incoming LoRa. Size: 20 Bytes, RSSI: -58dBm, SNR: 10.00dB, PacketCRC: 0xbc00, Total LoRa received: 5, CRC Ok Pct 100.00%
08:33:31.958 -> CRC Match, sending ACK packet to sensor 0xeb50(hex)
08:33:31.958 -> Transmitting LoRa message of size 11 bytes with CRC 0xffea to LoRa MAC 0xeb50
08:33:32.005 -> Sending Serial.
08:33:32.005 -> [{"id":2,"type":3,"data":49},{"id":2,"type":1,"data":21}]

Sensor:

08:33:31.726 -> FDRS User Node initializing...
08:33:31.726 ->  Reading ID 2
08:33:31.726 ->  Gateway: 1
08:33:31.726 -> Initializing LoRa!
08:33:31.726 ->  LoRa Initialized.
08:33:31.774 -> LoRa Band: 915000000.00
08:33:31.774 -> LoRa SF  : 7
08:33:31.774 -> Id: 2 - Type: 3 - Data loaded: 49.00
08:33:31.774 -> Id: 2 - Type: 1 - Data loaded: 21.00
08:33:31.774 -> Sending FDRS Packet!
08:33:31.774 -> Transmitting LoRa message of size 20 bytes with CRC 0xbc00 to gateway 0xee01. Retries remaining: 2
08:33:31.880 -> Incoming LoRa. Size: 11 Bytes, RSSI: -52dBi, SNR: 9.00dB, PacketCRC: 0xffea
08:33:31.880 -> ACK Received CRC Mismatch! Packet CRC is 0xffea, Calculated CRC is 0xebf5
08:33:31.880 -> Transmitting LoRa message of size 20 bytes with CRC 0xbc00 to gateway 0xee01. Retries remaining: 1, CRC OK 0.00%
08:33:31.958 -> Transmitting LoRa message of size 20 bytes with CRC 0xbc00 to gateway 0xee01. Retries remaining: 0, CRC OK 0.00%
08:33:32.005 -> Sleepytime!
08:33:32.005 ->  Deep sleeping.

Here is what the gateway looks like with your debugging functions enabled...

08:42:18.852 -> Incoming LoRa. Size: 20 Bytes, RSSI: -60dBm, SNR: 9.50dB, PacketCRC: 0x35ae, Total LoRa received: 3, CRC Ok Pct 100.00%
08:42:18.884 -> CRC Match, sending ACK packet to sensor 0xeb50(hex)
08:42:18.884 -> CRC: 00 : 0
08:42:18.884 -> CRC: 4F40 : 1
08:42:18.884 -> CRC: CC4E : 2
08:42:18.884 -> CRC: 78CC : 3
08:42:18.884 -> CRC: 95B9 : 4
08:42:18.884 -> CRC: B314 : 5
08:42:18.884 -> CRC: CF72 : 6
08:42:18.884 -> CRC: 254F : 7
08:42:18.884 -> CRC: F464 : 8
08:42:18.884 -> Transmitting LoRa message of size 11 bytes with CRC 0xffea to LoRa MAC 0xeb50
08:42:18.884 -> Printing packet of size 11.
08:42:18.884 -> 00: EB 50 
08:42:18.884 -> 02: EE 01 
08:42:18.918 -> 04: 03 01 
08:42:18.918 -> 06: 00 00 
08:42:18.918 -> 08: 00 FF 
08:42:18.918 -> 10: EA 
08:42:18.961 -> Sending Serial.
08:42:18.961 -> [{"id":2,"type":3,"data":0},{"id":2,"type":1,"data":21}]

[aviateur17]

@timmbogner, well some of my code has been lost and previous code is being used. The current code being used shows 0xFFFF as a CRC when ACK is not requested by my previous code had recalculated teh CRC with a known A1 value. This is how I noticed that my coding was lost. I don't know whether it is worth the time to figure out when that happened. I think the best step forward is to take the existing code and add back my changes to the affected functions and to test it out on my side. I'll go back into the previous changes and link to where I added my code so that you can see that it was added and how it differs from the code today. Let me know if you think that is the best path forward.

I know node vs sensor terminology was discussed before but I'm wondering what code is currently using the fdrs_sensor.h file? Looks pretty similar to fdrs_node.h so wondering can we delete fdrs_sensor.h or why it remains?

Thanks!
Jeff

[aviateur17]

@timmbogner, here's the commit that somehow didn't make it into the current code:
eed87ac

Not sure it's worth the time figuring out why that did not happen. Probably something in the consolidation of all of the files.

Jeff

[timmbogner]

Thanks Jeff. I was sort of afraid there had been some kind of code loss, but struggled to track down when and where. Surely my lack of git-skillz are to blame. I think what you've described is probably best, and hopefully it will give me a better understanding of what the heck I did and why.

fdrs_sensor.h was left in for backwards compatibility, and was (at one point) a carbon copy of fdrs_node.h. Needs to be deleted now.

[timmbogner]

@timmbogner, here's the commit that somehow didn't make it into the current code: eed87ac

Not sure it's worth the time figuring out why that did not happen. Probably something in the consolidation of all of the files.

Jeff

Gotcha, I will take a look later on today. Thanks again!

[timmbogner]

Hey Jeff, I'm reading through the datasheet for the SX1276-8 and it's really interesting! There are a lot of features that I didn't know were available. For example: There are both fixed and variable length packet configurations, and if we were to choose fixed-length we could put up to 2047 byte in a packet. We don't need to do this at all, I just had no idea it was an option.
There's also some simple addressing with the preamble and the chip-level CRC functionality. Was it the library preventing us from using the native CRC?
I'm working on switching to RadioLib and was looking up how the DIO0 pin acts in different modes. I am not actually sure how the current LoRa library deals with sends and receives behind the scenes, but with the new library both will be interrupt-driven.

I also thought this was nifty:

The payload to be transmitted may contain long sequences of 1's and 0's, which introduces a DC bias in the transmitted
signal. The radio signal thus produced has a non uniform power distribution over the occupied channel bandwidth. It also
introduces data dependencies in the normal operation of the demodulator. Thus it is useful if the transmitted data is random
and DC free.
For such purposes, two techniques are made available in the packet handler: Manchester encoding and data whitening.

[bvwelch]

Greetings, I also have some time and would enjoy the opportunity to work on whatever needs doing. I have a lot to learn about your cool project but have a fair amount of embedded systems experience. As you may recall I happen to be starting with a couple of the adafruit feather m0+lora boards but I also have some esp32 and esp8266 boards, and an assortment of sensors.

https://bvwelch.github.io/

[timmbogner]

Thanks a lot! Off the top of my head, the most pressing issue I can think of is this problem with gateways on the ESP32-C3. If you have one of those and some time, I think there's something easy but illusive keeping it from booting.
I am currently at a point where I just want to focus on bug fixes and stability for the most part. After working on the software side of this for so long, I'm really itching to work on implementing more nifty devices in the field, especially testing solar. I'm curious how well a gateway could work with a solar panel.
I'll keep thinking and let you know if I think of any cool projects!

[bvwelch]

I dont have one yet, but if you can recommend one, I will buy it, preferrably from amazon adafruit or sparkfun mouser digikey. I need to order some other items anyway. Bill

…

On Mon, Apr 24, 2023 at 8:38 PM Timm Bogner ***@***.***> wrote: Thanks a lot! Off the top of my head, the most pressing issue I can think of is this problem with gateways on the ESP32-C3 <#165>. If you have one of those and some time, I think there's something easy but illusive keeping it from booting. I am currently at a point where I just want to focus on bug fixes and stability for the most part. After working on the software side of this for so long, I'm really itching to work on implementing more nifty devices in the field, especially testing solar. I'm curious how well a gateway could work with a solar panel. — Reply to this email directly, view it on GitHub <#110 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACG5G2ZKNGR3EZVXEAFWR3XC4TI5ANCNFSM6AAAAAAQ6SVN6Q> . You are receiving this because you commented.Message ID: <timmbogner/Farm-Data-Relay-System/repo-discussions/110/comments/5714178@ github.com>

[timmbogner]

Well being honest, mine is just a random devkit-type board that I bought cheap on a whim when browsing AliExpress a couple years ago. I'm not sure I'd recommend buying it, especially just for this.
If you want to buy an ESP32-C3 anyway, my advice would be to look for a board that is interesting to you.

[bvwelch]

maybe this one? https://www.amazon.com/Seeed-Studio-XIAO-ESP32C3-Microcontroller/dp/B0B94JZ2YF/

…

On Tue, Apr 25, 2023 at 5:52 AM Timm Bogner ***@***.***> wrote: Well being honest, mine is just a random devkit-type board that I bought cheap on a whim when browsing AliExpress a couple years ago. I'm not sure I'd recommend buying it, especially just for this. If you want to buy an ESP32-C3 anyway, my advice would be to look for a board that is interesting to you. — Reply to this email directly, view it on GitHub <#110 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACG5GYZWMMOG6CNTYYIZODXC6UIVANCNFSM6AAAAAAQ6SVN6Q> . You are receiving this because you commented.Message ID: <timmbogner/Farm-Data-Relay-System/repo-discussions/110/comments/5718419@ github.com>

[timmbogner]

That would be good one probably! Fairly common, or at least I've seen them used in a few projects.

[bvwelch]

Hi, I ordered one of these XIAO C3 boards, and also, on impulse, a CubeCell Board: HTCC-AB01 But I read where you had some grief with a cubecell previously? So, should I cancel the cubecell? thanks!

[timmbogner]

Eh, it'll be interesting. I don't think using CubeCell boards has actually been attempted, just discussed. Generally I'd steer you towards LilyGo's offerings, which I think are more robust.

[bvwelch]

I will try to cancel that Cubecell board -- after some googling it may only have 16KB of RAM. And by the way the feather m0+lora only has 32KB, versus the esp32 boards you all are using have 320KB. And I think the esp3266 have 80KB.