[Xastir-dev] LORA and interfacing

Kristoff kristoff at skypro.be
Sun Aug 1 12:07:53 PDT 2021 

Hi Steve,


I must really look into the Rnode.
If you say that you put the rnode into sniffer mode so you could 
determine the spreading-factor, does this mean that the Rnode can do 
that automatically, or that you just tried all of different spreading 
factors  and found that SF12 worked?


Yes, SF12 packets are long, but that is exactly one of the features of 
digital communication: the possibility to 'tune' the transmission. The 
parameters are bandwidth, bitrate (speed), transmission-power and range.
It's like WSPR or QRSS. The transmissions are very long, but you can 
decode signals that are 20 to 30 db below the noise-floor.


If you look at page 20 of the sx1276 datasheet (*), there are some 
examples of the RF sensitivity with different SF values.
It's not linear, but roughly speaking, going down 1 step in the SF 
scale, you lose about 2 to 3 db of sensitivity.

So if you go down 2 steps in the SF scale, your bitrate will be 4 times 
faster, but you will loose some 40 to 50 % of range.



In the context of APRS, I think aprs-over-lora has a place for (say) 
portable or bicycle-mobile applications next to regular 1200 baud AFSK 
on VHF or UHF for (car) mobile use.
So I do not think that the lower bitrate of LoRa is that necessarily 
much of an issue.

I hope that aprs-over-lora will make applications like chat more popular 
as that is a feature of APRS that has deserves much more attention then 
what it gets.



Note.
I had a chat in the matrix-room of the GNU Radio community on Hamming 
FEC on the Coding-Rates.
The conclusion at this time is that -indeed- there is no reason to use 
Coding Rates 6 or 8. In both cases, they just add error-detection 
capability to CR5 or CR7; but as aprs-over-LoRa has CRC error-detection 
anyway, this does not add any value.

So the choice is this:
CR5: no error-correction, for radio-channels with little RF interference,
CR7: error-correction enabled, for radio-channels with more RF interference.


Keep in mind that a CR7 packet is 7/5 times the size of a CR5 packet.



73

kristoff - on1arf


(*) 
https://www.semtech.com/products/wireless-rf/lora-core/sx1276#download-resources


On 01.08.21 18:36, Steve wrote:
> Interesting that you mentioned coding rates.
>   I was sniffing  OE5BPA’s Lora transmitter because Xastir is not decoding
> it. I have a feeling his packets are not quite right over the air. You can
> put Rnode into a packet sniffer mode, which makes it easy to see things.
> OE5BPA’s config file has a default CR of 12… it is very long on its
> transmission. I changed it to CR of 5.
>
> Just a FYI… I’m just a person who has fun using this stuff, not a developer
> with coding  experience ..
>
> Steve N0FPF
>
> On Sun, Aug 1, 2021 at 5:27 AM Kristoff <kristoff at skypro.be> wrote:
>
>> Hi Steve,
>>
>>
>> Interesting code. I'll look into it. Perhaps it is a better option then
>> me building something (non-standard) myself.
>>
>>
>> Concerning modifying the Coding-Rate, I think one should look at this
>> per application.
>> APRS is mostly a 'broadcast' service the most logical thing to do is to
>> use one single 'standard' modulation-scheme for everything.
>>
>> However for a service like 'aprs-messages', although the traffic is
>> transmitted inside a 'broadcast' packet, it is still directed at one
>> specific destination.
>> In that case, the igate or digipeater can operate on that. If it keeps
>> track of the coding-rate of the last packet it received from that
>> station, it can use that information in its transmissions towards that
>> station.
>> (you can find the coding-rate of the last packet received in register
>> 0x18 of the chip).
>>
>> Concerning the coding-rate, yesterday I found this video from ccc 33c3
>> (2016), where Matt Knight explained how he reverse-engineered most of
>> the LoRa PHY (*)
>>
>> There is also this document from him. (**)
>>
>>
>> It had an interesting part in it where he explains the 4 transformations
>> done on the LoRa datastream, one of them is Hamming-coding Forward Error
>> correction.
>> His document has this on it:
>> --- cut here --- cut here ---
>>
>> A larger codeword size improves the robustness of the FEC: Hamming(5,4)
>> and (6,4) provide error detection as a parity bit would, whereas (7,4)
>> and (8,4) provide single bit correction with (8,4) additionally
>> providing dual error detection.
>> --- cut here --- cut here ---
>>
>>
>>
>> As I see it, going from FEC 4/5 to 4/7 is interesting as it adds the
>> possibility to do error-correction of a single bit.
>> Going from 4/7 to 4/8 does add the ability to detect more errors, but it
>> cannot correct it.
>>
>> Now, as APRS is a datacommunication-protocol (i.e. the content of the
>> data is unknown, so the whole packet must be correct or it will not be
>> processed) and the LoRa frame also has a CRC field, I do not see the
>> additional advantage of that 8th bit (i.e. 4/8 vs. 4/7). It may provide
>> more error-detection, but CRC does that anyway.
>>
>> So, as I see it, it looks that if you are in a area of bad coverage, it
>> is useful to use the 4/7 coding-rate instead of the standard 4/5, but
>> not 4/8 (as I previously mentioned). In fact, using 4/8 creates larger
>> packets then when using 4/7, which -I think- might be a disadvantage as
>> a bigger packets simply has more bits that can get corrupted.
>>
>>
>> But, as I not an expert on hammings FEC, I might be wrong.
>>
>> If somebody knows more about this, feel free to reply.
>>
>>
>>
>>
>> (*) https://media.ccc.de/v/33c3-7945-decoding_the_lora_phy#t=2382
>> (**) https://pubs.gnuradio.org/index.php/grcon/article/view/8
>>
>>
>> 73
>> kristoff - on1arf
>>
>>
>> On 31.07.21 22:38, Steve wrote:
>>> I’ve noticed that the KISS implementation on a lot of these devices is a
>>> forked over version of the Rnode. He used the Sx 1276 chip as well
>> because
>>> it has really good RX sensitivity at the lower rates. He also has a newer
>>> and easier form of KiSSattach.
>>> https://github.com/markqvist/tncattach
>>>
>>>
>>>
>>> I like your thoughts about changing modulation on the fly. I’ve seen it
>>> done with higher level stuff , Ubiquiti and others.  Just wonder how much
>>> it would slow things down. Cause I think you would do that per packet.
>>> Maybe per connection.
>>>
>>> Right now I’m just interested in tying a few of the different versions
>> and
>>> seeing what works. No real goals in mind, just checking it out and
>>> experimenting.
>>>
>>> I’ve thought about a repeater, but that would kill the great RX
>> sensitivity
>>> , but a digi would be good. A old style repeater separated by distance
>> and
>>> a link would work.
>>>
>>>
>>> Might even try Winlink on it and see what what happens when I stir that
>> pot!
>>> So many ideas.
>>>
>>> Steve N0FPF
>>>
>>> On Sat, Jul 31, 2021 at 12:58 PM Kristoff <kristoff at skypro.be> wrote:
>>>
>>>> Steve,
>>>>
>>>>
>>>> I also have this model:
>>>>
>>>>
>> https://www.amazon.nl/DollaTek-LoRa32-SD-kaart-draadloze-module/dp/B07RXSKPBX/
>>>> The disadvantage is that it lacks the 8 Mbit PSRAM chip (which is on the
>>>> T-beam) so the ESP32 is a bit short on memory for embedded python. (less
>>>> then 1 MByte of RAM available).
>>>>
>>>>
>>>> Software development-wize, perhaps it makes more sense to turn the
>>>> radio-device into just a dumb 'packet-modem', connect it to a
>>>> single-board computer (say, a raspberry pi) and do all development
>>>> overthere. That way you can run higher-level code, easily interface with
>>>> the internet, connect other devices (e.g. a VHF/UHF packet mode), etc.
>>>>
>>>> Last week, I found this python module for processing aprs message (*)
>>>> which I think would be a good basis to do some experimental development
>>>> for aprs-code.
>>>>
>>>>
>>>>
>>>>
>>>> I do like the sx1276 chip. It has a couple of nice features.
>>>>
>>>> - as it also has a FSK modem, It might also be able to transmit POCSAG
>>>> (paging) messages. If this works, we should be able to build a
>>>> APRS-to-POCSAG gateway with just one piece of hardware: send a aprs
>>>> text-message to a certain APRS node and it transmit that message as a
>>>> POCSAG paging message.
>>>>
>>>> I once wrote some code to create pocsag-message. (**)
>>>>
>>>>
>>>> - The automatic header-detection in lora is nice,
>>>> This means that if you send a packet with (say) a coding-rate of 4/8 to
>>>> a lora-node configured with 4/5, the chip will still receive and decode
>> it.
>>>> So, if you know that you are in area with bad APRS-over-lora coverage,
>>>> you can switch to a coding-rate that provides better error-correction
>>>> (like 4/8). Your packets will become larger (by 37.5 % in this case) but
>>>> your packet might still arrive, which it might not have done with a
>>>> coding-rate of 4/5.
>>>>
>>>> Note that that bandwidth and Spread-Factor do need to match. If not,
>>>> your packet will not be demodulated/decoded.
>>>>
>>>> - Another nice thing is that, although the chip does have CRC-generation
>>>> and CRC validation in silicon, it will still pass packets to the
>>>> receiver, even if they fail the CRC check.
>>>> It will flag it as 'CRC error', but the code on application-level will
>>>> still be able to retrieve it.
>>>> Most other radio-chips I have looked at so far do have do not do this
>>>> and will silently drop that message.
>>>>
>>>> This would allow for a nice lora "DX-ing" mode by implementing
>>>> additional error-correction code on application-level.
>>>>
>>>>
>>>>
>>>>
>>>> Ah yes, there is also a GNU Radio implementation of the Lora PHY. (***)
>>>> I haven't tried it yet, so I do not know if it works but It would be
>>>> interesting to experiment with this, e.g. tweaking the parameters even
>>>> further to do even further DX.
>>>>
>>>>
>>>>
>>>> I am not on Facebook.
>>>>
>>>> I prefer mailing-lists for in-depth discussions. To get real-time help,
>>>> ...  I am on matrix / element.io which is an open-source and
>>>> decentralized IM/voice/video service.
>>>> There are quite some open-source groups reachable via matrix, either
>>>> directly on matrix itself or via bridges to IRC or some other IM
>> protocol.
>>>> It's used the GNU Radio community.
>>>>
>>>>
>>>> (*) https://github.com/ampledata/aprs
>>>> (**) https://github.com/on1arf/pocsag
>>>> (***) https://www.epfl.ch/labs/tcl/resources-and-sw/lora-phy/
>>>>
>>>>
>>>> 73
>>>> kristoff - on1arf
>>>>
>>>>
>>>> On 31.07.21 20:31, Steve wrote:
>>>>> I gave two of the TTGO units including a couple of Rnodes.
>>>>>
>>>>> I’m going to try a couple of the existing firmware options out there.
>>>> Some
>>>>> are KISS based some are not. I like the possibility of using the wifi
>> or
>>>>> Bluetooth with the TTGO with some of the APRS programs fir the phones.
>>>>>
>>>>> Seems for a mobile device, not have a extra board such as a PI might be
>>>>> nice… we’ll see!
>>>>>
>>>>> The TTGO can also be used for this:
>>>>> https://tinygs.com
>>>>>
>>>>> The Rnode guy is also implementing a MESH system but is only in the
>> alpha
>>>>> stage. Beyond my ability.
>>>>>
>>>>> I’ll have to get back to you on Freq, I only got my TTGO going last
>> night
>>>>> and didn’t bother to look!
>>>>>
>>>>> There is a LORA APRS group on Facebook, grin, that is mostly from
>> Europe
>>>>> who have a lot of experience with this .
>>>>>
>>>>> Steve N0FPF
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 31, 2021 at 11:20 AM Kristoff <kristoff at skypro.be> wrote:
>>>>>
>>>>>> Steve,
>>>>>>
>>>>>>
>>>>>> Your project interests me too.
>>>>>>
>>>>>> We are using this hardware:
>>>>>> https://github.com/LilyGO/TTGO-T-Beam
>>>>>>
>>>>>> We are on 433.775 MHz, 150 KHz, SF12, 4/5
>>>>>> What frequency and what mode do you use?
>>>>>>
>>>>>>
>>>>>> The software comes from this project:
>>>>>> https://github.com/lora-aprs
>>>>>> But if the code of your project is standard arduino, it shouldn't be
>> to
>>>>>> difficult to port it to ESP32.
>>>>>>
>>>>>> Apparently, there are also some high-altitude balloon projects that
>> use
>>>>>> lora for their telemetry download.
>>>>>>
>>>>>>
>>>>>>
>>>>>> My personal interest is to use this for doing some software
>>>>>> experimentation, so I use micropython on the ESP32 (fast development)
>>>>>> and not the arduino code.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 73
>>>>>> Kristoff - on1arf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 31.07.21 20:05, Steve wrote:
>>>>>>> I connected it to my 10 db Omni antenna at home right at the base to
>>>>>>> minimize the loss.
>>>>>>>
>>>>>>> I was impressed that it was heard around some of the hills in west
>>>>>> seattle .
>>>>>>> I have plans to put a IGate at a high point around the end of the
>>>> summer.
>>>>>>> I also found a small bi- directional amp too.  Boost it to a watt or
>>>> two.
>>>>>>> Just don’t want to kill the receive sensitivity. Around $60.
>>>>>>>
>>>>>>> It’s all in the antenna.
>>>>>>>
>>>>>>> Steve N0FPF
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 31, 2021 at 10:59 AM Tom Russo <russo at bogodyn.org>
>> wrote:
>>>>>>>> On Sat, Jul 31, 2021 at 10:35:44AM -0700, we recorded a
>>>> bogon-computron
>>>>>>>> collision of the <stevewa206 at gmail.com> flavor, containing:
>>>>>>>>> I have interfaced the Rnode Lora device. It does Kiss and used a PI
>>>> 3.
>>>>>>>>> Pretty straight forward.
>>>>>>>>>
>>>>>>>>> https://unsigned.io/projects/rnode/
>>>>>>>>>
>>>>>>>>> I was able to do a client and a IGAte.
>>>>>>>> That is pretty cool!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Tom Russo    KM5VY
>>>>>>>> Tijeras, NM
>>>>>>>>
>>>>>>>>      echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr
>> [a-m][n-z]
>>>>>>>> [n-z][a-m]
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Xastir-dev mailing list
>>>>>>>> Xastir-dev at lists.xastir.org
>>>>>>>> http://xastir.org/mailman/listinfo/xastir-dev
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Xastir-dev mailing list
>>>>>> Xastir-dev at lists.xastir.org
>>>>>> http://xastir.org/mailman/listinfo/xastir-dev
>>>>>>
>>>> _______________________________________________
>>>> Xastir-dev mailing list
>>>> Xastir-dev at lists.xastir.org
>>>> http://xastir.org/mailman/listinfo/xastir-dev
>>>>
>> _______________________________________________
>> Xastir-dev mailing list
>> Xastir-dev at lists.xastir.org
>> http://xastir.org/mailman/listinfo/xastir-dev
>>

More information about the Xastir-dev mailing list