[Xastir-dev] LORA and interfacing

Sun Aug 1 05:27:41 PDT 2021

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
>>