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 <krist...@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 <krist...@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 <ru...@bogodyn.org>
wrote:
On Sat, Jul 31, 2021 at 10:35:44AM -0700, we recorded a
bogon-computron
collision of the <stevewa...@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@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev
_______________________________________________
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev
_______________________________________________
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev
_______________________________________________
Xastir-dev mailing list
Xastir-dev@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir-dev
