packets sent from routers only occassionaly pass partial packet check

[paidforby]

@Juul is it possible to remove the LoRa airtime delay from the network setup (radio.js) and perform it in the router (firmware.c) instead, we'll need to port it eventually anyway. The delay makes it very difficult to predict when a packet will be transmitted by the send_packet function. At least we could add an option to disable it for testing.

Simple test router code, attempting to send_packet every 5s, results in:

[node 0] 319.02, 626.56 - range: 1724.03 | snr: 0.35
Nodes within range of node 0: 0
[node 0] transmitting packet: test packet 0 
[node 0 router] initialized
--- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0] transmitting packet: test packet 1 test packet 2 t
[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping:

[node 0 router] --- looping

[node 0 router] --- looping

[node 0 router] --- looping

[node 0] transmitting packet: est packet 3 test packet 4 test packet 5 test packet 6 test packet 7 test packet 8 test packet 9 test packet 

[Juul]

Hrm wouldn't that defeat a large part of the purpose of the simulator? The actual radio takes that long to transmit the packet. There is no way around that, but if pretending that there's no delay helps you in the initial stages of routing algorithm development then sure, I can add an option to disable the delay. I don't think it makes sense to put it in the C code since the simulator has to know when the packet begins transmitting and when it is done transmitting (in order to calculate when two packets cause interference). The only other way to do that would be to have the C code send "tx start" and "tx end" messages which I feel would add complication with no real gain.

[Juul]

Re-reading your issue I think you may be misunderstanding the delay. When you transmit a packet on the SX1276 it takes some real amount of time to send the packet, which can be quite a long time due to the low bitrate. The simulator is simply simulating this.

[Juul]

It does look weird that your individual packets are getting chopped up like that though. If you push your code I can have a look.

[paidforby]

I understand the purpose of the delay. I also see why it needs to be known by the simulator to setup the network. However, this should not stop the firmware from repeatedly blasting messages. Obviously, this would be a bad thing to do because you would just keep trampling your own messages, but it is something that can be done with the actual hardware, so it should be possible with the simulator.

I suppose what I'm suggesting is to leave the delay in the network side, but stop it from limiting the firmware, so that we have to write an airtime calculator and delay messages as they are buffered in firmware. This will need to be done at some point anyway, since there won't be any god mode javascript running on the real network.

Pushing test code, if you want to take a look.

[paidforby]

but I suppose, if I write the same delay into the firmware, then it won't matter what the network is doing. I'll work on copying the airtime calculator code to the firmware.

[Juul]

Are you sure there is no way to ask the chip when the packet has completed sending (on the real hardware)?

…

On Sat, Sep 15, 2018 at 9:54 AM, grant_____ ***@***.***> wrote: but I suppose, if I write the same delay into the firmware, then it won't matter what the network is doing. I'll work on copying the airtime calculator code to the firmware. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHfgC91dmp7Qoi_K3-n6Dh0oJMjvTtGks5ubTCwgaJpZM4WqLqr> .

[paidforby]

Ok, I think I understand, the purpose of the delay is to emulate the TxDone sent by the DI0 pin of the LoRa transceiver. According to the arduino LoRa API docs, when sending a packet with LoRa.endPacket(), https://github.com/sandeepmistry/arduino-LoRa/blob/master/API.md#end-packet

LoRa.endPacket(async);
    async - (optional) true enables non-blocking mode, false waits for transmission to be completed (default)

I can't say I've ever noticed this blocking on the real hardware.
Would it make sense (is it possible?) to make the send_packet function blocking like the endPacket function? We could return the payload time from the node and then set a blocking delay based on that?

[Juul]

On Sat, Sep 15, 2018 at 7:47 PM, grant_____ ***@***.***> wrote: Ok, I think I understand, the purpose of the delay is to emulate the TxDone sent by the DI0 pin of the LoRa transceiver. According to the arduino LoRa API docs, when sending a packet with LoRa.endPacket(); LoRa.endPacket(async); async - (optional) true enables non-blocking mode, false waits for transmission to be completed (default) I can't say I've ever noticed this blocking on the real hardware.

It definitely blocks. Which is bad. We should be checking in the event loop rather than blocking.

Would it make sense (is it possible?) to make the send_packet function blocking like the endPacket function? We could return the payload time from the node and then set a blocking delay based on that?

I can change it so you get a function in the C code that can be called from within loop() to check if transmission is currently in progress. Probably not tonight though.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHfgMnQYNcevh_es_HCBIOSlmmmb4r8ks5ubbvYgaJpZM4WqLqr> .

[paidforby]

Great! Agreed, I'll rewrite the actual firmware to use the non-blocking mode of endPacket and add a function that checks for the TxDone interrupt. Then we just need the simulator to do something similar.

[paidforby]

for reference, check out recent PR sandeepmistry/arduino-LoRa#62

[Juul]

Wait, if there is a TxDone interrupt then we should implement that as a callback that gets triggered in the C code by the simulator. I'll have a look tonight.

…

On Sun, Sep 16, 2018 at 11:28 AM, grant_____ ***@***.***> wrote: Great! Agreed, I'll rewrite the actual firmware to use the non-blocking mode of endPacket and add a function that checks for the TxDone interrupt. Then we just need the simulator to do something similar. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHfgEeGHqaWzWQ1RxK019A-OoPR1otSks5ubphAgaJpZM4WqLqr> .

[paidforby]

If you look at page 38 and page 46 of the SX1276 datasheet you can see references to the TxDone interrupt, I believe this was used to enable non-blocking mode in that PR. You can see the lines they added here, https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L172 (though isTransmitting() is private and trying to beginPacket() is the recommended way of checking if chip is transmitting, which is syntactically weird, but appears to work well).

[paidforby]

So I think I discovered the true cause of my problems. After a closer look at the airtime delay, I noticed that this is only ever a couple 100ms, so there was no way it was causing the few second delay I was seeing.

However, in node.js, the data is retrieved from the c process by this.router.stdout.on('data', function(data)... this contains an if statement that looks for partial packets. For some reason it thinks that every packet after the first sent by the c process is partial (in fact it thinks the first one is partial, but it succeeds in sending, for unclear reasons). Tried putting \0 and \n and even just 0, but nothing worked in forcing the packet to be considered not partial. I'm going to comment out the partial packet detection for now, we should put it back once it's tested and working.

Also, this doesn't mean we shouldn't add an isTransmitting() function to the router code to match the real hardware.

[paidforby]

This issue is stale. Also partial packets (if we decide to support such a thing) should be handled by the routing protocol, not by the simulator js code, which should be nothing more than a dumb pipe between neighboring node.