- Welcome to LowPowerLab Forum.
Recent posts
#71
General topics / Re: Dropped Packets with High ...
Last post by Felix - July 16, 2025, 05:28:58 PMOh interesting. There's a related forum post where the user reports the Teensy as causing their issues 
I think that was one of the first things I suggested eliminating as a variable to see if it reduces the problem
I think that was one of the first things I suggested eliminating as a variable to see if it reduces the problem
#72
General topics / Re: Dropped Packets with High ...
Last post by Aerokeith - July 16, 2025, 05:25:31 PMThanks. By the way, I reduced the Teensy 4's clock rate from 600MHz to 100MHz, and that seemed to reduce the drop rate in the intermittent-tx scenario. No drops at all when sending/receiving continuously.
#73
RF - Range - Antennas - RFM69 library / Re: Would RFM69W be more relia...
Last post by Felix - July 16, 2025, 05:20:46 PMThanks for the update.
Coincidentally there's another Teensy related post right now where some dropped packet issues are happening.
Coincidentally there's another Teensy related post right now where some dropped packet issues are happening.
#74
General topics / Re: Dropped Packets with High ...
Last post by Felix - July 16, 2025, 05:18:10 PMSorry I didn't reply yet, I did read through the post but didn't have a better suggestion so wasn't sure what alternatives I could recommend.
What you are trying is what I would probably try as well.
There are many variables in the radio configuration. This is certainly more of an edge case and perhaps the library is not optimized for this so you might have to tweak the library functions to try and see if that gets you closer. I just don't have insight without trying to solve the exact problem you're facing.
What you are trying is what I would probably try as well.
There are many variables in the radio configuration. This is certainly more of an edge case and perhaps the library is not optimized for this so you might have to tweak the library functions to try and see if that gets you closer. I just don't have insight without trying to solve the exact problem you're facing.
#75
General topics / Re: Dropped Packets with High ...
Last post by Aerokeith - July 16, 2025, 05:08:57 PMSorry to bug you. Can you at least confirm that the approach I'm using should work, and that it's not unusual? I keep looking for something stupid I've done, but no luck so far.
#76
RF - Range - Antennas - RFM69 library / Re: Would RFM69W be more relia...
Last post by midix - July 16, 2025, 05:25:26 AMJust an update, in case someone happens to encounter the same weird stutter.
It turned out to be something Teensy-related! As soon as I replaced Teensy with ATmega32U4-based board, the weird 200ms delay went away. I have no idea if the problem is with Teensy itself or the NRF24L01+ libraries.
It turned out to be something Teensy-related! As soon as I replaced Teensy with ATmega32U4-based board, the weird 200ms delay went away. I have no idea if the problem is with Teensy itself or the NRF24L01+ libraries.
#77
Pi Gateway / Re: Running on PROXMOX LXC
Last post by Uncle Buzz - July 12, 2025, 04:53:39 PMThe nedb that was installed with the script was not the latest version on your GitHub (which I believe is the latest version from Louischatriot). It threw an exception about IsDate from Utils. I changed utils.IsDate to utils.types.IsDate, which solved the problem and allowed the app to start correctly.
After finding the link to your nedb GitHub fork, I checked your code and saw another correction to mine. I manually copied your repo of nedb and didn't notice any difference, but everything is working correctly right now. I'm not sure if it's related or if it's related to some browser extensions I have uniloaded. I have to investigate further, but it works!
After finding the link to your nedb GitHub fork, I checked your code and saw another correction to mine. I manually copied your repo of nedb and didn't notice any difference, but everything is working correctly right now. I'm not sure if it's related or if it's related to some browser extensions I have uniloaded. I have to investigate further, but it works!
#78
Pi Gateway / Running on PROXMOX LXC
Last post by Uncle Buzz - July 12, 2025, 08:14:38 AMHi,
I'am trying to run the gateway app on a proxmox container LXC (not a VM) and I have some strange behavior...
I created a container with Debian 12.2 amd64 base, pass the USB device to the CT and installed the gateway app via the github script (version 9.2.1)
I'm able to run the app, getting node data, seams to be almost good... apart from following :
The node is auto generated when gateway receives new message, but I'm not able to edit or save any update since the node is reset at each new message, like the autogeneration was always executed even if the node already exists.
When I reload the webpage, the node list I void, but I can't add a node already known, and it appears on the GUI when a new message is received.
I'm not able to set a new label nor description, nor new event (I'm trying to add mqtt event which is correctly set and connect to the mqtt broker thanks to this topic
I wonder if all this strange stuff is due to the container, or library version from the debian 12 repository, or any misconfiguration.
Do you have any idea Felix ?
I'am trying to run the gateway app on a proxmox container LXC (not a VM) and I have some strange behavior...
I created a container with Debian 12.2 amd64 base, pass the USB device to the CT and installed the gateway app via the github script (version 9.2.1)
I'm able to run the app, getting node data, seams to be almost good... apart from following :
The node is auto generated when gateway receives new message, but I'm not able to edit or save any update since the node is reset at each new message, like the autogeneration was always executed even if the node already exists.
When I reload the webpage, the node list I void, but I can't add a node already known, and it appears on the GUI when a new message is received.
I'm not able to set a new label nor description, nor new event (I'm trying to add mqtt event which is correctly set and connect to the mqtt broker thanks to this topic
I wonder if all this strange stuff is due to the container, or library version from the debian 12 repository, or any misconfiguration.
Do you have any idea Felix ?
#79
General topics / Re: Dropped Packets with High ...
Last post by Aerokeith - July 11, 2025, 06:50:18 PMQuoteI applaud your perseverence, it pays off.Thanks, it's really important that I get this working in within the next week.
Your message describes the normal operations of send() and receiveDone(), which I think I understand reasonably well. But I don't see any clues that would help me find or fix the problem. Maybe I should describe what I'm doing (in my test code) in more detail to see if it gives you any ideas of new things to try:
Transmit
The main loop calls send() every 100ms to send a 61 byte packet where the first byte contains a packet sequence number that is incremented every iteration. The bit rate is 100 Kbps.
Receive
The main loop repeatedly calls receiveDone() to check for a received packet, with no delays within the loop. If a packet is received, the packet sequence number is checked to see if there's a gap in the expected sequence. Errors are reported, but no other processing is performed (for this test).
It's pretty simple, but doesn't work correctly (no packet drops) until the transmit-side delay is reduced to less than the duration of a single packet (~6ms).
In this condition, send() is being called before the last bits of the previous packet have been transmitted. That's normal, I know. But when the delay is increased, send() is called when the previous transmission is completed (which I assume turns off the transmitter). So I'm guessing that there's some sort of delay in turning the transmitter back on such that the RFM module isn't fully ready to transmit the first bits of the packet, which get corrupted. I tried adding a setMode(RFM_MODE_TX) before the call to send() but that had no effect.
Any better ideas?
#80
General topics / Re: Dropped Packets with High ...
Last post by Felix - July 11, 2025, 05:08:44 PMI applaud your perseverence, it pays off.
The send() will just modulate the packet then switch the radio in STANDBY mode, it cannot be left in TX mode or it would continuously modulate the carrier and not only eat up a lot of current, but also block the channel, it would be a terrible waste.
One call to receiveDone() will check if there is data received and if not it places the radio in RX mode, it eats around 15mA, but it stays there, it's needed if you expect an incoming packet at any undetermined time, once a packet is received it will read the packet and go into STANDBY mode.
A call to receiveBegin() just forces the RX mode regardless (this is called by receiveDone())
So i misunderstood initially - you definitely want comfortable separation if you transmit in parallel. I call for 300kbps if you have the room and don't need many channels tight together. Even 1mhz if there is no concern. Too much will start suffering if the antennas tuning frequency is very sharp, but 1mhz should be just fine with most antennas, and in your case at very short range a few db missed because of slight antenna mismatch is no concern.
The send() will just modulate the packet then switch the radio in STANDBY mode, it cannot be left in TX mode or it would continuously modulate the carrier and not only eat up a lot of current, but also block the channel, it would be a terrible waste.
One call to receiveDone() will check if there is data received and if not it places the radio in RX mode, it eats around 15mA, but it stays there, it's needed if you expect an incoming packet at any undetermined time, once a packet is received it will read the packet and go into STANDBY mode.
A call to receiveBegin() just forces the RX mode regardless (this is called by receiveDone())
So i misunderstood initially - you definitely want comfortable separation if you transmit in parallel. I call for 300kbps if you have the room and don't need many channels tight together. Even 1mhz if there is no concern. Too much will start suffering if the antennas tuning frequency is very sharp, but 1mhz should be just fine with most antennas, and in your case at very short range a few db missed because of slight antenna mismatch is no concern.