support for adafruit feather m0 with rfm95 lora module?

[bvwelch]

Greetings,

I happen to have a couple of these boards, and they work with the radiohead library. I think they should work with radiolib as well.

If there is no support, may I try and see if they work? I have some esp32 and esp8266 modules and they work with your system fine.

thanks for a cool project

[timmbogner]

Hello, I just tried compiling a LoRa repeater for the Adafruit Feather M0 and it was successful. I don't have any board like it to test on, but I think we're on the right track! From looking at the pinout, I think this configuration shout work for you:

#define RADIOLIB_MODULE SX1276  // Adafruit RFM95
#define LORA_SS    8
#define LORA_RST   4
#define LORA_DIO   7
#define LORA_BUSY  RADIOLIB_NC

Thanks for reaching out, and please let me know if it works!

[bvwelch]

Thank you for your quick reply. I was able to compile/run a couple of examples but so far, the transmit is not received. I will try some of the RadioLib examples (without your Farm code), and possibly try a mix of RadioLib on one end, and RadioHead on the other.

[timmbogner]

I just published the sketches I've been using to test my RadioLib configuration when in a pickle. Hope it's helpful.

[bvwelch]

Thanks that was helpful -- my board has the IRQ on D3, not on 7.

Now I am looking into my next bug -- I think it may be serial -- not esp32 or esp8266 but something different for feather m0 I guess.

By the way in my scenario, I also have an old avr 328 could be added to your farm repo if you like -- it is kind of like the tpl5110 -- it is always powered on but very low battery drain, and, for example, when the mailbox flag is raised, a reed switch will notify the 328 and it will actually power-up the feather m0/lora ( because I haven't managed to get ultra low power out of the feather yet)

[bvwelch]

Well I tracked down the next problem -- DynamicJsonDocument doc(24576) fails on my M0 ( it only has 32K ram). I made a quick hack on all references to such calls and changed them to 500. And it seems to be running better. But maybe my M0 is just too small to be worth considering for your repo?

[timmbogner]

That giant ArduinoJson buffer issue has been on my radar for a bit. I think there is probably a more efficient way to use that library's API, but I just haven't gotten around to reading up on it. I'm a bit under the weather at the moment, but I'll try to look into that issue by this weekend.

[timmbogner]

I'm overall a bit behind on things right now, but I am still looking into this. I will post an update when I've found the best course of action for updating Arduino Json usage in FDRS.

[aviateur17]

Thinking about the Json memory allocation I think we know the size of memory that ArduinoJson recommends based on the assistant calculation - like 56 or 80 for a DataReading. When creating the Json object we know the number of DataReadings that need to be sent which is in the variable ln or s (depending upon the function). So I think we can just take 80 times ln and use that number for a memory allocation.

Now, if there is not enough memory in the controller or the memory allocation fails for some reason I'm not sure how we can handle that. I think the call to serializeJson may return some value to check to see if it succeeds and if it does we can sent to MQTT or Serial or whatever. If the check fails, perhaps we can serialize half of the DataReadings at a time and make several attempts at sending the data.

[timmbogner]

Cool, I think that's pretty much how I was thinking too. I think the big size was using the assumption that the document may need to contain up to 256 JSON DataReadings. I guess I just added JSON functionality three years ago, and then put off optimizing it until this week.🤨 I'm trying to think what scenario I thought would necessitate a buffer that large, or why I didn't scale it with the actual size.

If the check fails, perhaps we can serialize half of the DataReadings at a time and make several attempts at sending the data.

That's a good idea, I hadn't even thought that far ahead. At the end of the day, my goal is to run FDRS on an Uno. Seems like it should be possible, but I dunno.

[bvwelch]

Greetings, I appreciate you are working on reducing the RAM usage, but I don't think it should hinder all of the other cool things you all are working on.

So, maybe what I can do, is to implement a point-to-point m0+lora link, without actually using the FDRS library at all, and then connect the UARTs on each end of the lora link, to esp32 boards that are using FDRS.

I am not sure if you have already done something like this already??? I don't know what the terminology would be in FDRS-speak -- UART-BRIDGE?

Something like this:

home/base - ESP32/FDRS:uart - uart:M0+LORA --- M0+LORA:uart - ESP32/FDRS ... other FDRS

I would hope that the point-to-point link would be a small arduino app that should be able to run on other boards in my junk box that have smallish RAM, like the avr 328.

Admittedly this isnt for everyone -- you would need a lora breakout, like the adafruit rfm95 which costs $20. Or find a buddy who can do the smt soldering for you and build your own rfm95.

[timmbogner]

I think I'd call it a UART link or UART bridge, and it's a valid way to go about things. It's where FDRS's modularity comes in handy.

Did you get it to work by lowering the JSON document size? I was under the impression you had that working.

[bvwelch]

Did you get it to work by lowering the JSON document size? I was under the impression you had that working.

Yes changing the size to 500 'works' for now, but I presume it will likely break in the future.

[timmbogner]

I'm not really sure, but think the "breaking point" for that should be sending like... 7+ readings at once in a single array (I'm still not 100% sure on the sizes). You could test it by sending the following over serial:

[{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 }]

My assumption is that it will fail somehow. My guess is that it will cut off the JSON at the size of the doc, and then you'll get a parsing error.

My solution to all of this will probably be dropping it to 3072. Would that number be agreeable with the M0? Apologies that I'm not testing this myself, I'm going to get my testing setup in order and start doing code stuff this week.

[bvwelch]

thanks i will give it a try soonest!

On Mon, May 1, 2023 at 8:41 PM Timm Bogner @.***> wrote:

I'm not really sure, but think the "breaking point" for that should be sending like... 7+ readings at once in a single array (I'm still not 100% sure on the sizes). You could test it by sending the following over serial:

[{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 },{ id: 1, type: 6, data: 384 }]

My assumption is that it will fail somehow. My guess is that it will cut off the JSON at the size of the doc, and then you'll get a parsing error.

My solution to all of this will probably be dropping it to 3072. Would that number be agreeable with the M0? Apologies that I'm not testing this myself, I'm going to get my testing setup in order and start doing code stuff this week.

— Reply to this email directly, view it on GitHub https://github.com/timmbogner/Farm-Data-Relay-System/issues/157#issuecomment-1530755172, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACG5G5OAAH3JWXOCQE5JQ3XEBQ4VANCNFSM6AAAAAAWPFNVQU . You are receiving this because you authored the thread.Message ID: @.***>

[bvwelch]

This might be another use for a uart link:

https://stuartsprojects.github.io/2021/12/24/Serial-Bridge.html

On Sat, Apr 29, 2023 at 4:56 PM Timm Bogner @.***> wrote:

I think I'd call it a UART link or UART bridge, and it's a valid way to go about things. It's where FDRS's modularity comes in handy.

Did you get it to work by lowering the JSON document size? I was under the impression you had that working.

— Reply to this email directly, view it on GitHub https://github.com/timmbogner/Farm-Data-Relay-System/issues/157#issuecomment-1528881322, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACG5G5K7DGQ3A232BR2BYDXDWFABANCNFSM6AAAAAAWPFNVQU . You are receiving this because you authored the thread.Message ID: @.***>

[timmbogner]

Hi @aviateur17 and @bvwelch, I was jumping back into this issue with ArduinoJson's document size. I just saw that ArduinoJson version 7 will be released officially any day now, and now features an "elastic" object size. This should eliminate the question altogether, so that's good. I made a new 'arduinojson7' branch with the changes. I installed ArduinoJson 7 by cloning the repo and switching to the '7.x' branch. I think I will start it as a pull request, then wait until the library makes v7 official to commit the changes.

[timmbogner]

ArduinoJson7 & support is now live!