[Xastir-dev] LORA and interfacing

Steve stevewa206 at gmail.com
Sun Aug 1 13:37:14 PDT 2021 

https://meshtastic.org/


Another interesting effort.


Steve N0FPF

On Sun, Aug 1, 2021 at 12:34 PM Steve <stevewa206 at gmail.com> wrote:

> You have to set the Rnode with the parameters you want to sniff. So I had
> to set the baud rate, bandwidth and CR to match the other tracker.
>
> A lot of gadgets that are doing off the grid chat are using the Lora
> chips. I’ve been watching these guys.
> https://www.sonnetlabs.com
>
> They say their code is open source..
>
>
>
>
> On Sun, Aug 1, 2021 at 12:08 PM Kristoff <kristoff at skypro.be> wrote:
>
>> 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
>> >>
>> _______________________________________________
>> 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.
>
-- 
Pardon the brevity, sent from a mobile device. So there.

More information about the Xastir-dev mailing list