Digipeating issue ... #249

New Issue

2026-10-05T05:53:47+02:00

adam commented

2026-10-05 05:53:47 +02:00

Hello!

In the last days I was busy building a LoRa Digipeater and now it is running for testing purposes on my balcony (next to my iGates). I noticed a slightly odd behavour with some digipeated packets. But first here is my setup:

LoRa Tracker OE5REO-6
TX on 433.775
Heltec Wireless Tracker with the latest firmware V2.4.2

LoRa iGate 1 OE5REO-11
RX on 433.775
Lilygo Lora32 V1.6 with the latest firmware V3.1.7

LoRa iGate 2 OE5REO-12
RX on 433.900
Lilygo Lora32 V1.6 with the latest firmware V3.1.7

LoRa Digipeater OE5REO-13
RX 433.775 <-> TX 433.900
Heltec Wireless Stick Lite with the latest firmware V3.1.7

The digipeater seems to work fine, it RX on 433.775 and then re-TX the beacon on 433.900. I choose a cross-frequency setting to keep the traffic on the main LoRA QRG as low as possible. But some packets are being re-transmitted twice ... please see the screenshots:

The packet at 13:39:04 was received by my main iGate (OE5REO-11) and sent to APRS-IS. My digipeater heard that packet also and digipeated it a few seconds later. My second iGate (OE5REO-12) heard that packet at 13:39:09 and sent it to APRS-IS. So far so good ...

But about two minutes later the digipeater sent that packet again with a strange path and the last part missing?!?

I noticed the same behavour a few hours before with OE6HEF-8:

I am aware that running a digipeater and an iGate simultaniously does not make sense ... this is just for testing, the digipeater will later go to a remote place in the mountains where there is no LoRa infrastructure so far.

Is this a bug or did I misconfigure something? I'm clueless ...

73 Martin
OE5REO

Hello! In the last days I was busy building a LoRa Digipeater and now it is running for testing purposes on my balcony (next to my iGates). I noticed a slightly odd behavour with some digipeated packets. But first here is my setup: **LoRa Tracker [OE5REO-6](https://en.aprs.fi/info/a/OE5REO-6)** TX on 433.775 Heltec Wireless Tracker with the latest firmware V2.4.2 **LoRa iGate 1 [OE5REO-11](https://en.aprs.fi/info/a/OE5REO-11)** RX on 433.775 Lilygo Lora32 V1.6 with the latest firmware V3.1.7 **LoRa iGate 2 [OE5REO-12](https://en.aprs.fi/info/a/OE5REO-12)** RX on 433.900 Lilygo Lora32 V1.6 with the latest firmware V3.1.7 **LoRa Digipeater [OE5REO-13](https://en.aprs.fi/info/a/OE5REO-13)** RX 433.775 <-> TX 433.900 Heltec Wireless Stick Lite with the latest firmware V3.1.7 The digipeater seems to work fine, it RX on 433.775 and then re-TX the beacon on 433.900. I choose a cross-frequency setting to keep the traffic on the main LoRA QRG as low as possible. But some packets are being re-transmitted twice ... please see the screenshots: <img width="1182" height="53" alt="Image" src="https://github.com/user-attachments/assets/bc119b93-34f6-471b-8345-d08ac81c4a26" /> <img width="1416" height="108" alt="Image" src="https://github.com/user-attachments/assets/7e751b50-5915-46a1-93be-5c4d737c64f9" /> The packet at 13:39:04 was received by my main iGate (OE5REO-11) and sent to APRS-IS. My digipeater heard that packet also and digipeated it a few seconds later. My second iGate (OE5REO-12) heard that packet at 13:39:09 and sent it to APRS-IS. So far so good ... But about two minutes later the digipeater sent that packet again with a strange path and the last part missing?!? I noticed the same behavour a few hours before with OE6HEF-8: <img width="2362" height="193" alt="Image" src="https://github.com/user-attachments/assets/b95eeeec-77da-4737-90ad-12c3398950f8" /> <img width="1318" height="205" alt="Image" src="https://github.com/user-attachments/assets/367a8e4b-568e-4142-be11-7d6d95b5303c" /> I am aware that running a digipeater and an iGate simultaniously does not make sense ... this is just for testing, the digipeater will later go to a remote place in the mountains where there is no LoRa infrastructure so far. Is this a bug or did I misconfigure something? I'm clueless ... 73 Martin OE5REO

adam closed this issue

2026-10-05 05:53:47 +02:00

adam commented

2026-10-05 05:53:48 +02:00

there is clearly some strange thing working there with OE5REO-13

"TOCALL, WIDE1-1:payload" should change to "TOCALL, OE5REO-13*:payload" ....

can you please test without OE5REO-11 to have only one igate listening for the packets?

there is clearly some strange thing working there with OE5REO-13 "TOCALL, WIDE1-1:payload" should change to "TOCALL, OE5REO-13*:payload" .... can you please test without OE5REO-11 to have only one igate listening for the packets?

adam commented

2026-10-05 05:53:48 +02:00

I diabled the iGate OE5REO-11 (433.775) and now only have the digipeater OE5REO-13 and the 2nd iGate OE5REO-12 (433.900) running. I went for a quick drive around the area to test it right away ...

I found 99 packets on APRS.fi afterwards. About 2/3 of them were received and gated via other iGates. And 1/3 was received and gated via OE5REO-13 (digipeater) and OE5REO-12 (iGate).

Two packets had the same issue which I described before:

If you take a look at the second screenshot please notice the delay of 10 minutes ... and again the last three letters of the payload are missing! That's probably the reason why it says [Too short packet]

I will leave the iGate OE5REO-11 disabled for the next days and see how the digipeater performs.

I diabled the iGate OE5REO-11 (433.775) and now only have the digipeater OE5REO-13 and the 2nd iGate OE5REO-12 (433.900) running. I went for a quick drive around the area to test it right away ... I found 99 packets on APRS.fi afterwards. About 2/3 of them were received and gated via other iGates. And 1/3 was received and gated via OE5REO-13 (digipeater) and OE5REO-12 (iGate). Two packets had the same issue which I described before: <img width="602" height="180" alt="Image" src="https://github.com/user-attachments/assets/4e602f6a-7fc7-4f41-8e16-786acee35309" /> <img width="587" height="98" alt="Image" src="https://github.com/user-attachments/assets/713a19cc-d7ba-49b0-b6a5-bcaeee4c20ad" /> If you take a look at the second screenshot please notice the delay of 10 minutes ... and again the last three letters of the payload are missing! That's probably the reason why it says **[Too short packet]** I will leave the iGate OE5REO-11 disabled for the next days and see how the digipeater performs.

adam commented

2026-10-05 05:53:49 +02:00

And here is a screenshot of the WebUI of OE5REO-12:

And here is a screenshot of the WebUI of OE5REO-12: <img width="1435" height="772" alt="Image" src="https://github.com/user-attachments/assets/f220a381-50ae-4bb5-8af4-35a02c1a5b21" />

adam commented

2026-10-05 05:53:50 +02:00

still strange that the digipeater is added both ways there... also with the delay... what other digipeaters are there listening ??

looks like the second "copy" with the time-delay of 10min is clearly something wrong / but could not see how it could be doing this.

still strange that the digipeater is added both ways there... also with the delay... what other digipeaters are there listening ?? looks like the second "copy" with the time-delay of 10min is clearly something wrong / but could not see how it could be doing this.

adam commented

2026-10-05 05:53:50 +02:00

There are no other digipeaters in the area ...

But I noticed the following ... this will probably help??

I have the beacon of OE5REO-13 set to TX every 30 minutes.

So the last beacon of OE5REO-13 was TXed at:

19:31.58
19:01:58
18:32:06
18:02:04

The problem only seems to happen when OE5REO-13 is TXing its own beacon. Then it seems to send the last digipeated beacon again.

The problem occured at 18:02:04 and 18:31:59 ... thats 2-3 seconds before the digipeater sends out its own beacon.

I will have a look at it in the next days. Probably I will change:

to BEACON ON RX FREQ and see if the problem still occurs.

There are no other digipeaters in the area ... But I noticed the following ... this will probably help?? I have the beacon of OE5REO-13 set to TX every 30 minutes. So the last beacon of OE5REO-13 was TXed at: 19:31.58 19:01:58 18:32:06 18:02:04 The problem only seems to happen when OE5REO-13 is TXing its own beacon. Then it seems to send the last digipeated beacon again. The problem occured at 18:02:04 and 18:31:59 ... thats 2-3 seconds before the digipeater sends out its own beacon. I will have a look at it in the next days. Probably I will change: <img width="457" height="133" alt="Image" src="https://github.com/user-attachments/assets/01bfe621-b3ab-4034-b864-27a828cdf1aa" /> to **BEACON ON RX FREQ** and see if the problem still occurs.

adam commented

2026-10-05 05:53:51 +02:00

ok, test it out and let me know how it goes

ok, test it out and let me know how it goes

adam commented

2026-10-05 05:53:52 +02:00

adam commented

2026-10-05 05:53:52 +02:00

I have reprogrammed the digipeater to

The own packets (every 30 Min.) are now TXed on 433.775
The digipeated packets are TXed on 433.900

Let's see if the problem still exists then.

I have reprogrammed the digipeater to <img width="466" height="222" alt="Image" src="https://github.com/user-attachments/assets/3dac24ad-77e0-4b38-9693-7b8acc654862" /> The own packets (every 30 Min.) are now TXed on 433.775 The digipeated packets are TXed on 433.900 Let's see if the problem still exists then.

adam commented

2026-10-05 05:53:53 +02:00

Sorry, but today I noticed that the digipeater also sends theses strange packets when in BEACON ON RX FREQ mode. Every time this happens the digipeater is sending out it's own position packet a few seconds later:

Very strange, but I can definatelly say that it only happens shortly before the digipeater is sending out the own position packet ...

Sorry, but today I noticed that the digipeater also sends theses strange packets when in **BEACON ON RX FREQ** mode. Every time this happens the digipeater is sending out it's own position packet a few seconds later: --- <img width="1146" height="21" alt="Image" src="https://github.com/user-attachments/assets/2c1e6de3-e740-4c94-ac08-e2d56459c1e0" /> <img width="1263" height="21" alt="Image" src="https://github.com/user-attachments/assets/7bfbefe5-07d9-447a-aafa-5af0978494c8" /> --- <img width="1152" height="21" alt="Image" src="https://github.com/user-attachments/assets/50a960d0-cf13-4004-945f-3e0d9b4c1941" /> <img width="1258" height="21" alt="Image" src="https://github.com/user-attachments/assets/88d95f44-117a-4449-9de2-966208b1ba72" /> --- <img width="1155" height="21" alt="Image" src="https://github.com/user-attachments/assets/0e7e92e0-c1da-4e33-a17d-3bc6a2d0cfac" /> <img width="1263" height="21" alt="Image" src="https://github.com/user-attachments/assets/c40215e6-5d31-4b8f-9d57-0c93ad151603" /> --- <img width="1156" height="21" alt="Image" src="https://github.com/user-attachments/assets/86a1317f-3eae-4784-87b4-cf5e7150b9ab" /> <img width="1266" height="21" alt="Image" src="https://github.com/user-attachments/assets/f6f38297-e5e5-488b-9f77-1197a1428de3" /> --- <img width="1164" height="21" alt="Image" src="https://github.com/user-attachments/assets/82e71ef7-6249-4173-b2be-e2c0a51d3687" /> <img width="1263" height="21" alt="Image" src="https://github.com/user-attachments/assets/de87b7cd-04ce-43c9-bfe1-f7f47f81ffda" /> --- Very strange, but I can definatelly say that it only happens shortly before the digipeater is sending out the own position packet ...

adam commented

2026-10-05 05:53:54 +02:00

--- <img width="1159" height="21" alt="Image" src="https://github.com/user-attachments/assets/71b1478f-1b58-49c2-a454-f05e59578ac3" /> <img width="1263" height="21" alt="Image" src="https://github.com/user-attachments/assets/6afac947-f05b-412e-8a10-8ae340b02d20" /> --- <img width="1159" height="21" alt="Image" src="https://github.com/user-attachments/assets/6350f2e0-0971-41eb-84c5-1a4f8946b8ad" /> <img width="1263" height="21" alt="Image" src="https://github.com/user-attachments/assets/50379445-44c4-4cd9-ad6e-02061216d156" /> ---

adam commented

2026-10-05 05:53:54 +02:00

Some days ago I installed the battery powered digipeater at a high altitude location in the mountains. Today I made a hike at a location close to the digipeater and my beacons were forwarded without any problems. Due to the mountainous region not a single packet would have been received without the digipeater:

The digipeater is working great ... but every 60 minutes (some seconds before the digipeater is sending out it's own beacon) these false beacons are being transmitted:

Some days ago I installed the battery powered digipeater at a high altitude location in the mountains. Today I made a hike at a location close to the digipeater and my beacons were forwarded without any problems. Due to the mountainous region not a single packet would have been received without the digipeater: <img width="1336" height="1393" alt="Image" src="https://github.com/user-attachments/assets/9d0d4a32-758e-4da2-8ece-81adf6567609" /> The digipeater is working great ... but every 60 minutes (some seconds before the digipeater is sending out it's own beacon) these false beacons are being transmitted: <img width="620" height="938" alt="Image" src="https://github.com/user-attachments/assets/1c0641e8-0567-4684-a9b9-429bf800ffda" /> <img width="650" height="98" alt="Image" src="https://github.com/user-attachments/assets/7722593f-6ea7-4e78-8754-3d0a8577d97e" />

adam commented

2026-10-05 05:53:55 +02:00

will check this as this is clearly not an expected behavior (which version of the iGate/digi are you running ? )

will check this as this is clearly not an expected behavior (which version of the iGate/digi are you running ? )

adam commented

2026-10-05 05:53:56 +02:00

Hardware
Heltec Wireless Stick Lite

Firmware
V3.1.7

Digipeater
Ultra Eco Mode

**Hardware** Heltec Wireless Stick Lite **Firmware** V3.1.7 **Digipeater** Ultra Eco Mode

adam commented

2026-10-05 05:53:57 +02:00

Hardware Heltec Wireless Stick Lite

Firmware V3.1.7

Digipeater Ultra Eco Mode

any way to get the .json file to check it also ?

> **Hardware** Heltec Wireless Stick Lite > > **Firmware** V3.1.7 > > **Digipeater** Ultra Eco Mode any way to get the .json file to check it also ?

adam commented

2026-10-05 05:53:57 +02:00

it is up on the mountain at 1500m ASL ... a hike of 1 1/2 hours and we had 30cm of fresh snow last night ... so not really possible in the next days. but I made screenshots of my settings on the web-ui if this helps?

it is up on the mountain at 1500m ASL ... a hike of 1 1/2 hours and we had 30cm of fresh snow last night ... so not really possible in the next days. but I made screenshots of my settings on the web-ui if this helps?

adam commented

2026-10-05 05:53:58 +02:00

And not sure how to get the .json file out of the device when it is in "Ultra Eco Mode"??

Probably with the query ?EM=OFF and then connect to the device?

And not sure how to get the .json file out of the device when it is in "Ultra Eco Mode"?? Probably with the query **?EM=OFF** and then connect to the device?

adam commented

2026-10-05 05:53:59 +02:00

And not sure how to get the .json file out of the device when it is in "Ultra Eco Mode"??

Probably with the query ?EM=OFF and then connect to the device?

exactly... just exit the UltraEcoMode, download the .json configuration file and get back into UEM.

> And not sure how to get the .json file out of the device when it is in "Ultra Eco Mode"?? > > Probably with the query **?EM=OFF** and then connect to the device? exactly... just exit the UltraEcoMode, download the .json configuration file and get back into UEM.

adam commented

2026-10-05 05:53:59 +02:00

it is up on the mountain at 1500m ASL ... a hike of 1 1/2 hours and we had 30cm of fresh snow last night ... so not really possible in the next days. but I made screenshots of my settings on the web-ui if this helps?

this also helps, just to validate a few things instead of the hike

> it is up on the mountain at 1500m ASL ... a hike of 1 1/2 hours and we had 30cm of fresh snow last night ... so not really possible in the next days. but I made screenshots of my settings on the web-ui if this helps? this also helps, just to validate a few things instead of the hike

adam commented

2026-10-05 05:54:00 +02:00

this also helps, just to validate a few things

sent you an e-mail with the screenshots

> this also helps, just to validate a few things sent you an e-mail with the screenshots

adam commented

2026-10-05 05:54:01 +02:00

this also helps, just to validate a few things

sent you an e-mail with the screenshots

received! What if the "personal note" is getting into the data which is causing it to be as noise in the Path construction?

> > this also helps, just to validate a few things > > sent you an e-mail with the screenshots received! What if the "personal note" is getting into the data which is causing it to be as noise in the Path construction?

adam commented

2026-10-05 05:54:01 +02:00

what PATH are you using on the OE5REO-4 ???

what PATH are you using on the OE5REO-4 ???

adam commented

2026-10-05 05:54:02 +02:00

What if the "personal note" is getting into the data which is causing it to be as noise in the Path construction?

Not thought about that but that could be an explaination!?

what PATH are you using on the OE5REO-4 ???

I use the PATH "WIDE1-1" on all my trackers ... the problem also happens with other stations, these are the four stations I noticed this behavour:

OE6HEF-8
OE5MIL-11
OE5REO-6
OE5REO-4

Please see the older screenshots above

> What if the "personal note" is getting into the data which is causing it to be as noise in the Path construction? Not thought about that but that could be an explaination!? > what PATH are you using on the OE5REO-4 ??? I use the PATH "WIDE1-1" on all my trackers ... the problem also happens with other stations, these are the four stations I noticed this behavour: OE6HEF-8 OE5MIL-11 OE5REO-6 OE5REO-4 Please see the older screenshots above

adam commented

2026-10-05 05:54:03 +02:00

I have another Heltec Wireless Stick Lite here. I could set-up a clone of OE5REO-13 and leave the "Personal Note" empty and see if the problem goes away ...

I have another Heltec Wireless Stick Lite here. I could set-up a clone of OE5REO-13 and leave the "Personal Note" empty and see if the problem goes away ...

adam commented

2026-10-05 05:54:03 +02:00

I have another Heltec Wireless Stick Lite here. I could set-up a clone of OE5REO-13 and leave the "Personal Note" empty and see if the problem goes away ...

test it please, with a different Personal Note or no note at all and let me know... will double check it

> I have another Heltec Wireless Stick Lite here. I could set-up a clone of OE5REO-13 and leave the "Personal Note" empty and see if the problem goes away ... test it please, with a different Personal Note or no note at all and let me know... will double check it

adam commented

2026-10-05 05:54:04 +02:00

I did set up a clone using the SSID OE5REO-14 ... in the PERSONAL NOTES I wrote:

OE5XXX-13

Here is what happened:

So it looks like that it has nothing to do with the PERSONAL NOTES ...

I did set up a clone using the SSID OE5REO-14 ... in the PERSONAL NOTES I wrote: **OE5XXX-13** Here is what happened: <img width="1419" height="255" alt="Image" src="https://github.com/user-attachments/assets/f51abcf1-742b-4c79-aa23-8221b13e1625" /> <img width="1176" height="58" alt="Image" src="https://github.com/user-attachments/assets/614d8c25-dc4b-43b7-a79d-e5a5b8b934a0" /> So it looks like that it has nothing to do with the PERSONAL NOTES ...

adam commented

2026-10-05 05:54:05 +02:00

So it looks like that it has nothing to do with the PERSONAL NOTES ...

thanks for the validation... will check it again into the way the digipeater packet is built

> So it looks like that it has nothing to do with the PERSONAL NOTES ... thanks for the validation... will check it again into the way the digipeater packet is built

adam commented

2026-10-05 05:54:05 +02:00

quick question: is this working in CROSS FREQUENCY?? (RX freq and TX freq not the same?)

quick question: is this working in CROSS FREQUENCY?? (RX freq and TX freq not the same?)

adam commented

2026-10-05 05:54:06 +02:00

yes ....rx 433775 tx 433900

yes ....rx 433775 tx 433900

adam commented

2026-10-05 05:54:06 +02:00

yes ....rx 433775 tx 433900

found the bug.. will try to address it soon!

> yes ....rx 433775 tx 433900 found the bug.. will try to address it soon!

adam commented

2026-10-05 05:54:07 +02:00

@richonguzman

Did you do any changes regarding this digipeater issue to the latest firmware V3.2.X? I will visit my remote digipeater in the next 2-3 weeks and if this bug is corrected I will upload the new firmware ...

@richonguzman Did you do any changes regarding this digipeater issue to the latest firmware V3.2.X? I will visit my remote digipeater in the next 2-3 weeks and if this bug is corrected I will upload the new firmware ...

adam commented

2026-10-05 05:54:08 +02:00

@richonguzman

Did you do any changes regarding this digipeater issue to the latest firmware V3.2.X? I will visit my remote digipeater in the next 2-3 weeks and if this bug is corrected I will upload the new firmware ...

this should be corrected with V3.2.2 Release ;) .... please test it (too)

> [@richonguzman](https://github.com/richonguzman) > > Did you do any changes regarding this digipeater issue to the latest firmware V3.2.X? I will visit my remote digipeater in the next 2-3 weeks and if this bug is corrected I will upload the new firmware ... this should be corrected with V3.2.2 Release ;) .... please test it (too)

adam commented

2026-10-05 05:54:08 +02:00

@richonguzman

I think there is a major bug in the digipeater in V3.2.2 ... i just uploaded the new firmware to my Heltec Wireless Stick Lite:

RX 433.775
TX 433.900
Ultra-Eco-Mode

Most of the received packets do not get digipeated. After plugging in the digipeater sometimes the first received beacon is digipeated, all the other following beacons are not digipeated at all. I was using a SDR to check what was going on the QRG's ... once the digipeater even stopped transmitting a received packet after a few moments (only a part of the packet was re-TXed).

Vy strange behavour ...

@richonguzman I think there is a major bug in the digipeater in V3.2.2 ... i just uploaded the new firmware to my Heltec Wireless Stick Lite: RX 433.775 TX 433.900 Ultra-Eco-Mode Most of the received packets do not get digipeated. After plugging in the digipeater sometimes the first received beacon is digipeated, all the other following beacons are not digipeated at all. I was using a SDR to check what was going on the QRG's ... once the digipeater even stopped transmitting a received packet after a few moments (only a part of the packet was re-TXed). Vy strange behavour ...

adam commented

2026-10-05 05:54:09 +02:00

Check the serial output that the station is giving you (stop the DigiEcoMode to see the packet) If your packet has a formatting fault or something messing on the way it gets built then it won't get digipeated)

Check the serial output that the station is giving you (stop the DigiEcoMode to see the packet) If your packet has a formatting fault or something messing on the way it gets built then it won't get digipeated)

adam commented

2026-10-05 05:54:10 +02:00

Sorry, don't know how to go into "SERIAL OUTPUT" on the digipeater.

I used my tracker OE5REO-4 for the test. It is just a few meters away from the digipeater ... so decoding the signal correctly should not be a problem. It simply does not digipeat the RX'ed packets (only the first one).

When I power-up the digipeater again it is digipeating the first received packet, but then again it stops digipeating.

Sorry, don't know how to go into "SERIAL OUTPUT" on the digipeater. I used my tracker OE5REO-4 for the test. It is just a few meters away from the digipeater ... so decoding the signal correctly should not be a problem. It simply does not digipeat the RX'ed packets (only the first one). When I power-up the digipeater again it is digipeating the first received packet, but then again it stops digipeating.

adam commented

2026-10-05 05:54:10 +02:00

put any other station hearing the packets, there should be enough information to know why is getting repeated and not the others.

When you flash the board you can also use the webpage to see the Serial Output of it (just dont use it as Digipeater in ultra ecomode to see the output)

put any other station hearing the packets, there should be enough information to know why is getting repeated and not the others. When you flash the board you can also use the webpage to see the Serial Output of it (just dont use it as Digipeater in ultra ecomode to see the output)

adam commented

2026-10-05 05:54:11 +02:00

i tried again and it seems to work now, don't know what was the problem before. i configured the digipeater and will bring it to the remote mountain location in the next weeks (still waiting for the replacement battery).

i will keep you updated on this subject ...

i tried again and it seems to work now, don't know what was the problem before. i configured the digipeater and will bring it to the remote mountain location in the next weeks (still waiting for the replacement battery). i will keep you updated on this subject ...

adam commented

2026-10-05 05:54:12 +02:00

I tested all possibilities for it, hope your testing goes good this days

I tested all possibilities for it, hope your testing goes good this days

adam commented

2026-10-05 05:54:12 +02:00

Due to a late return of winter and the long-lasting battery in my digipeater it took me longer than expected to visit the digipeater again. But today I did the hike ...

The digipeater was working for the last 2 month with a LiFePO4 20AH 3,3V cell which was still over 3,2V today. The complete hardware is in perfect shape, no sign of (water) damage. I uploaded the new firmware and in the first few hours of operating it looks as if it is now working without these strange digipeater issue I mentioned in this thread.

So I guess we can close this thread! Thanks to @richonguzman for finding the bug!

Next step of this project will be to build a solar-powered digipeater and bring it up the summit in 1-2 months ...

73 Martin
OE5REO

Due to a late return of winter and the long-lasting battery in my digipeater it took me longer than expected to visit the digipeater again. But today I did the hike ... The digipeater was working for the last 2 month with a LiFePO4 20AH 3,3V cell which was still over 3,2V today. The complete hardware is in perfect shape, no sign of (water) damage. I uploaded the new firmware and in the first few hours of operating it looks as if it is now working without these strange digipeater issue I mentioned in this thread. So I guess we can close this thread! Thanks to @richonguzman for finding the bug! Next step of this project will be to build a solar-powered digipeater and bring it up the summit in 1-2 months ... 73 Martin OE5REO

adam commented

2026-10-05 05:54:13 +02:00

good news

good news

Sign in to join this conversation.

main

Batt-comment-fix

IS2-mod

test-RP

updates-before-4.0.4

LoRa-Settings-fix

Tbeam1W

gps-sleep-fix

setPower-LoRa

supreme-update

aprspacketlib-message-update

payload-message-fix

sendCommentAfterXBeacons

map-html-security-fix

commit-update

WiFi-Password-error-management

rxDate-on-RX-Packets-in-webui

mDNS-update-fix

GPS-BAUD-RATE-AUTO-DETECT

update-CAD-timeout

Digipeater-updates-Morifef

solar-light-gateway-update

oled-screen-timeout-fix-in-AP-mode

newboard230926-3

ntp-update-change

new-Board-Indonesia

revision-loop-wifi

RP2350-add

limpieza-de-nombres-de-placas

new-board-RAK3312-RAK3112

further-fixes-v106

clean-parts-of-APRSPacketLib

aprspacketlib-105

fixes-geoscott

tnc-with-tnc2-update

TestPRJohnRokicki

24px-symbols

better-symbols

icons-on-map

preconfig-v4

geokscott-fix

query-answer-tacticall-fix

new-digi-mode

map_test1

CAD_1

richonguzman-patch-19

RPC-LoRa-DigiGate-1W

richonguzman-patch-18

lora32_GPS-add

richonguzman-patch-17

Tbeam-AXP192-and-sx1262-915-add

new-json

stackTraceFixOta

SP_V3.2.2

backBefore-FIX-OTA

RadioLib-moved-to-7.6.0

clean-saveNewDigiEcoModeConfig

VEXT-CTRL-fix

new-board_9M2IBR_ESP32

justCleanBeforeV3-2

blackList-update

25segBufferHash

backToDigi1

betterCleaningCode

digi-correction

masDigiBackUp

correccionCPU

moreHeltecV2

digiBackUpFix-plus-tactical

digi-backup-fix

Tactical

Heltec-v4

elegantOta-3.1.7

decodingFix

richonguzman-patch-16

heltec-Wireless-Paper-v1.2

HELTEC-Vision-Master-E290

APRS-IS-passcode-blocking-fix

newDeco

TXCO-fix

INA219-2

radiolib-excludes

add-AHT20

more-mods-aprspacketlib

richonguzman-patch-15

mqtt-beacon-fix

TNC-mas

NTP-server-fix

RxTxv3131

RxTxFreq

startup-delay

Freq-Beacon-Selection

self-mqtt-beacon

Op-defined-ntp_server

richonguzman-patch-14

richonguzman-patch-13

richonguzman-patch-12

richonguzman-patch-11

richonguzman-patch-10

richonguzman-patch-9

richonguzman-patch-8

richonguzman-patch-7

WirelessBridge

before3.1.2

newOTA

config-size-correction

LoRaHAM_V2

richonguzman-patch-6

richonguzman-patch-5

before3.1-2

tnc-name-fix

before3.1

heltec_paper_v12

more-Lora-posibilities

mqttVersionUpdate

mqtt-Fix

mqtt-Add

sleeperSyslog

coreTest

statusChange

acdMod

gpsPressureCorrection

corrections20250726

tncBuffer

richonguzman-patch-4

richonguzman-patch-3

richonguzman-patch-2

richonguzman-patch-1

UEM9

UEM8

HTCT62-fix1

UEM7

QRP-LG-Plus

QRP-LG-Plus-sleep

UEM6-1

UEM6

UEM5

UEM4

UEM3

UEM2

UEM1

timestamp-decoding

NewPR_LB5JJ

ethernet_001

updateMods_PETRKR

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/LoRa_APRS_iGate#249