[Xastir-dev] LORA and interfacing

Steve stevewa206 at gmail.com
Sun Aug 1 09:36:12 PDT 2021 

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
>
-- 
Pardon the brevity, sent from a mobile device. So there.

More information about the Xastir-dev mailing list