Closed robgil closed 3 years ago
What is happening in buildDatagram
? It needs to do something like, based on disaster radio Console.cpp
uint8_t GATEWAY[ADDR_LENGTH] = {0xc0, 0xd3, 0xf0, 0x0c};
struct Datagram datagram;
char msgBuff[128]; // get your temp and humidity data into here, or sprintf it directly into datagram.message
msgLen = sprintf((char *)datagram.message, "%s", msgBuff);
memcpy(datagram.destination, GATEWAY, ADDR_LENGTH);
datagram.type = 'c';
It's a a little weird because the address needs to be raw bytes, not ASCII chars, which can be difficult because arduino wants to make everything strings. But if the destination address is wrong, then the packet will appear to never be received by the receiver, since it's the address in the datagram does not match its local address. This reminds me that I need to write some sender/receiver example code.
And don't get too excited about all those neighbors, its a known bug reported here, https://github.com/sudomesh/disaster-radio/issues/81#issuecomment-691722197, I'll take a look at that as soon as I get a chance.
@paidforby Thanks! I figured it out and am now receiving messages on the receiver.
Turns out I had to set the following for it to work.
char MAC[9] = "c0d3f00c";
uint8_t LOCAL_ADDRESS[ADDR_LENGTH] = {0xc0, 0xd3, 0xf0, 0x0c}; <-- Datagram wants the hex here.
uint8_t GATEWAY[ADDR_LENGTH] = {0xc0, 0xd3, 0xf0, 0x0c};
LL2->setLocalAddress(MAC); <-- was looking for char here
It would be handy if the Datagram accepted the char array vs. the raw. I see there are a bunch of functions for converting this already. This will definitely hang other folks up, so I'm glad we figured it out. I'll give a swing at writing a simple client (I already did most of it!)
Great! Glad you figured it out. Yeah, it's a funny mix of chars and bytes. The reason the Datagram struct takes bytes is because it's actually the datagram that is copied into the packet so making it take individual chars for each hex character would waste bytes. I guess, some conversion could be done in the LL2->writeData function. I was actually thinking of changing that writeData function so it doesn't take a datagram, but instead takes the inputs to a datagram, something like, LL2->writeData(char *destination, char type, char * message)
. That would make sense, right?
And thanks for that pull request, I'll review and merge it (i looked good to me and is certainly better than nothing).
@paidforby yeah, I think the change to of LL2->writeData
makes sense. Especially as a higher level function.
I also noticed another issue, not sure if it is possible cause of your routing table being filled imprroperly, but you should not use delay()
in the loop, this is a blocking function that prevent the LL2 daemon from polling often enough. Instead of delay()
, write a poll that waits for a certain timeout to execute its function, like what is done inside of LL2->daemon() here, https://github.com/sudomesh/LoRaLayer2/blob/master/src/LoRaLayer2.cpp#L671
I made a number of changes in these two recent commits including,
Updated to latest LoRaLayer2 commit in the platformio.ini for both examples
Added LL2->init()
that was missing, I'm not sure it this was causing many problems because all it does is initialize some timeout counters, but still it should be called.
Corrected the packetsize
length to be the datagramsize
, you were adding HEADER_LENGTH
(i.e. the LL2 packet header) instead of DATAGRAM_HEADER
(just the datagram portion header), so there was extra data appended to the end of your hello messages.
Both the sender and receiver had the same local address, I corrected this by changing the receiver to something more distinct.
These changes seem to have fixed the issue with the routing table filling with garbage, though it's difficult to prove the negative, so all I can say is that I haven't observed that problem since making these changes (specifically, updating LL2 seemed to fix most of the routing table weirdness).
Sorry that I didn't take a look at this sooner.
@paidforby excellent thanks! Good catch on the packetsize and init bits. I'll try updating these and see if I still get a mess of random neighbors.
I see your point about using delay(). The example you mentioned makes perfect sense when running in active mode all the time. I'll open a separate issue / example for doing deep sleep which is really where that comes from. I used delay()
to emulate an ESP32 deep sleep. This unfortunately prevents packets from being sent since they seem to be getting sent asyncronously. We may need a way to flush the packet buffer before going to sleep.
This might be obvious, but I can't seem to parse the messages being sent via
LL2->writeData
. I haven't written c++ since college, but I don't think its my code, but likely I'm using the library? shrugThe setup is simple.
Sender Address: c0d3f00d Receiver Address: c0d3f00c
Receiver Side
Output as follows
BTW, shocked to see all these other neighbors.
Sender Side