Might want to enable terminal local echo for the demo @3:13. Just seeing the text pop up in a window was confusing until I was able to follow which terminal had focus. Thanks for the great product! I need this to communicate out-of-band (non-WiFi) between prototype devices across the house.
Thanks for the feedback! Sorry, it is a bit confusing but one window is where the data is sent, the other window shows the data being received. Yes - these radios will work great for out-of-WiFi band communication.
I like LoRa because it works well around the house. It's cool you can get long range line of sight, but the penetration power at close range is unreal. FYI - The tutorials link in the description is broken.
@@sparkfun Ah, I think he's referring to the tutorial link in the video description. We just need a space between the link and the end parenthesis `)` .
neat product. a few questions. what is the max baud rate of the serial it can send/rec? can this be configured to have multiple clients. i.e. 1 server talking to 8 or 16 or more client units at the same time?
Because it uses UART the most you'll get out of it is 115K baud and because it's a low horsepower SAMD1 (by today's standards) it'll likely start dropping transmissions at those speeds. The safest speed for UART is 9600 baud usually for debugging. A safe, reliable, and fast speed for a SAMD21 with LORA would probably be around 19K or so. My RFM95 with a 125Mhz RP2040 does 125K baud reliably, runs neopixels, a servo motor, and I2S audio, simultaneously! You can't do that with a 50Mhz Cortex M0 SAMD21 it just doesn't have enough RAM or horsepower. For a single purpose LORA radio running Arduino yes it'll work but you won't be able to do much more with it than be a transmitter or receiver. I should also add that I prefer using Circuit Python which is much more RAM and MCU intensive than the Arduino language. So my needs are more... intensive.
@@Willy_Tepes it’s possible. You’d want to tweak some settings to prioritize speed over reliability in some circumstances but you’ll still hit a transmission speed limit. Trying to tx/rx without encryption leaves your rc car susceptible to interference. Some random packet could make you turn left instead of right. So reliability is good to have but also reduces transmission speed (lag).
Yes, in Lora you can define 3 different parameters separate from the actual transmitting power. Spreading Factor - How much we "spread" our data over time. Max # is 12 Each step up in Spreading Factor doubles the airtime to transmit. Each step up in Spreading Factor adds about 2.5db extra link budget. Bandwidth - How big of a slice of the spectrum we use. Each doubling of the bandwidth is almost 3db less link budget. Bandwidths less than 31 may be unstable unless you have a high quality Crystal Oscillator. Coding Rate - How much redundancy we encode to resist noise. Increasing coding rate increases reliability while decreasing data-rate. 4/5 - 1.25x overhead 4/6 - 1.5x overhead 4/7 - 1.75x overhead 4/8 - 2x overhead
That's because most of the transmission buffer is likely taken up by the 256bit encryption... which doesn't leave a lot of room left for actual data. The RFM96 modules are known for this when encryption is enabled. The RFM95 doesn't have encryption, everything is transmitted in the open which allows you to send a paragraph of data. As Rudy De Volder said it's a trade off. Everything from speed, distance, scattering, and encryption is a trade off. You have to know what your design goal is in order to choose the right LORA module for your uses, there are different types out there which offer different features. If you want encryption by default then something like this product is a beautiful thing right out of the box. Easy pairing, super long distance, and encryption is a great combination. It's honestly an amazing offering if those features are within your design goal.
