scenario: In the future, it is possible to update your node on your 200-foot tower by simply sending the firmware file directly to the node with a zero hop direct connection
I know short fast can get about 10kbps (1KB/s) across the link, but thats just too slow to send a 1.5MB firmware update. I know that short turbo is illegal in some places, and I believe it’s because it’s using a bandwidth of 500KHz instead of the 250KHz of short fast.
So if you turn the error correction way down to almost off what is about the maximum bandwidth you could hope to possibly get out of the LoRa connection at 250KHz?
Even if you could pull off 125kbps (12.5KB/s) that would only require two minutes to send the firmware file from your node to the receiving node up on the tower.
According to the SX1261/2 datasheet, the maximum RAW bit rate of this LoRa chip is 62.5 kb/s for 500 KHz bandwidth and spreading factor of 5.
The bit rate is constrained by the spreading factor and the bandwidth. Bandwidth is constrained by law, spreading factor is constrained by design. You can find the details in LoRa™ Modulation Basics, AN1200.22, section 4.
For 250 KHz Lora, you can use the equation to get the theoratical max:
If we set SF = 5, BW = 250,000, bit rate is 39.0625 kb/s for a raw bit stream.
So, I think that the limit of 62.5 kb/s is a safe speed ceiling to consider. I am not sure how you would get 125 kbps using LoRa and current constraints. You could switch the chip to FSK mode and pull at 300 kb/s IF the FSK link is strong enough.
Sooo, 1998 “USR X2” dial-up speeds.
1.5mb is okay. 32mb we used ‘at’ to schedule (just so we’d get the mail when it was done) and go to lunch.
Keep in mind, when USENet was in full swing, we had entire institutions daisy-chained off a single 56k incoming line like a trunk line, from America to Vancouver through Edmonton and then Calgary. The best and brightest surfed binaries and alts like mad off that single chain.
It’s really usable if we tune our workflow.