#1 2015-05-16 00:17:42

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

MicroDigi beta - standalone digipeater firmware

Hi all!
I've just posted the code for MicroDigi on github, a new firmware for MicroModem that allows it to run as a standalone digipeater. Please note that the firmware should be considered early beta quality. I have tested it quite well in a simulated environment, but it has not been tested in the field yet. So I'd suggest not using this for unattended live installations just yet. So far the firmware supports FILL-IN and WIDEn-N digipeating. For now there is no precompiled images, since you need to set your callsign and other options in the config.h file. When you have configured it to your liking, you can compile and flash the firmware, and it is ready to digipeat. I hope you will report any bugs you find, and suggest features you would like to see! Here's the link for the repo:

https://github.com/markqvist/MicroDigi

Cheers,

Mark

Offline

#2 2015-05-16 09:06:50

G4ZAL
Member
Registered: 2015-04-28
Posts: 14

Re: MicroDigi beta - standalone digipeater firmware

Hi Mark,

I saw the files during the middle of the evening, downloaded the repo, built a hex file and loaded it to my Pro Mini (running @ 5v but with a 3v3 ADC).
I think I grabbed it before your last change/upload later in the night, so will make a new hex file.

It was receiving and decoding live data and appeared to be re-transmitting as the Tx LED was lighting up (I didn't have it physically cabled to the Tx).
Monitoring the serial port, it reported WIDE-1 and WIDE-2 with the appropriate packets (but nothing else outputted to the serial line).

I'll report back when I get some time to make some proper tests (busy weekend coming up !!).

Nigel.

Offline

#3 2015-05-16 17:15:06

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Dear Mark,

I've download the github, edited the config.h and compiled the hex and uploaded to the MicroModem ( Mini Pro 5V )

After that, I open a Serial port @ 9600 to monitor the status ... I did not get anything from the Serial port even when the handy Rx LED was light up... the MicroModem Rx or Tx LED did not lit up either ...

To double confirm the MicroModem hw is fine, I re-flash back to MicroAPRS firmware and it was working fine ... decoded packets and such ....

Did I missed out something ??


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#4 2015-05-16 17:25:56

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

BTW I got these warnings during compilation :-

Starting build...
Compiling: main.c
In file included from main.c:7:0:
util/time.h:18:5: warning: '__iCliRetVal' is static but used in inline function 'timer_clock' which is not static [enabled by default]
In file included from main.c:6:0:
util/FIFO.h:70:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_pop_locked' which is not static [enabled by default]
util/FIFO.h:63:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_push_locked' which is not static [enabled by default]
util/FIFO.h:56:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isfull_locked' which is not static [enabled by default]
util/FIFO.h:48:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isempty_locked' which is not static [enabled by default]
Compiling: hardware/Serial.c
hardware/Serial.c: In function 'serial_init':
hardware/Serial.c:21:5: warning: initialization from incompatible pointer type [enabled by default]
hardware/Serial.c:21:5: warning: (near initialization for 'uart0_fd.put') [enabled by default]
hardware/Serial.c:21:5: warning: initialization from incompatible pointer type [enabled by default]
hardware/Serial.c:21:5: warning: (near initialization for 'uart0_fd.get') [enabled by default]
Compiling: hardware/AFSK.c
hardware/AFSK.c: In function 'AFSK_init':
hardware/AFSK.c:77:5: warning: initialization from incompatible pointer type [enabled by default]
hardware/AFSK.c:77:5: warning: (near initialization for 'afsk_fd.put') [enabled by default]
hardware/AFSK.c:77:5: warning: initialization from incompatible pointer type [enabled by default]
hardware/AFSK.c:77:5: warning: (near initialization for 'afsk_fd.get') [enabled by default]
In file included from hardware/AFSK.h:10:0,
                 from hardware/AFSK.c:2:
hardware/AFSK.c: At top level:
./util/time.h:18:5: warning: '__iCliRetVal' is static but used in inline function 'timer_clock' which is not static [enabled by default]
In file included from hardware/AFSK.h:9:0,
                 from hardware/AFSK.c:2:
./util/FIFO.h:70:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_pop_locked' which is not static [enabled by default]
./util/FIFO.h:63:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_push_locked' which is not static [enabled by default]
./util/FIFO.h:56:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isfull_locked' which is not static [enabled by default]
./util/FIFO.h:48:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isempty_locked' which is not static [enabled by default]
Compiling: util/CRC-CCIT.c
Compiling: protocol/AX25.c
In file included from protocol/../hardware/AFSK.h:10:0,
                 from protocol/AX25.c:8:
./util/time.h:18:5: warning: '__iCliRetVal' is static but used in inline function 'timer_clock' which is not static [enabled by default]
In file included from protocol/../hardware/AFSK.h:9:0,
                 from protocol/AX25.c:8:
./util/FIFO.h:70:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_pop_locked' which is not static [enabled by default]
./util/FIFO.h:63:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_push_locked' which is not static [enabled by default]
./util/FIFO.h:56:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isfull_locked' which is not static [enabled by default]
./util/FIFO.h:48:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isempty_locked' which is not static [enabled by default]
Compiling: protocol/Digipeater.c
In file included from protocol/../hardware/AFSK.h:10:0,
                 from protocol/Digipeater.h:4,
                 from protocol/Digipeater.c:6:
./util/time.h:18:5: warning: '__iCliRetVal' is static but used in inline function 'timer_clock' which is not static [enabled by default]
In file included from protocol/../hardware/AFSK.h:9:0,
                 from protocol/Digipeater.h:4,
                 from protocol/Digipeater.c:6:
./util/FIFO.h:70:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_pop_locked' which is not static [enabled by default]
./util/FIFO.h:63:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_push_locked' which is not static [enabled by default]
./util/FIFO.h:56:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isfull_locked' which is not static [enabled by default]
./util/FIFO.h:48:3: warning: '__iCliRetVal' is static but used in inline function 'fifo_isempty_locked' which is not static [enabled by default]
Linking: images/MicroDIGI.elf
avr-objcopy: --change-section-lma .eeprom=0x00000000 never used

AVR Memory Usage
----------------
Device: Unknown

Program:    7108 bytes
(.text + .data + .bootloader)

Data:       1624 bytes
(.data + .bss + .noinit)



Firmware compiled successfully!
[email protected] ~/MicroDigi $
[email protected] ~/MicroDigi $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#5 2015-05-16 20:50:06

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

Nigel, it seems you got one of the versions that were not completely done. That version with the "Detected WIDEx-X" (some debug output) did not have duplicate detection for instance. The current version had that output removed smile

Stanley, the current version is quiet on the output port, unless you enable SERIAL_DEBUG in the "device.h" file! That's why you're not seeing any data on the serial port. By default the current version is also configured to only act on WIDE2-x packets, which means that if you live in an area where the general path settings are higher than 2 hops, you should adjust this to allow a higher DIGIPEATER_CLAMP_N setting in the config.h file.

Interesting with those warnings, I haven't seen them before. Do you also get them when compiling MicroAPRS on the same system?

Offline

#6 2015-05-16 23:13:04

G4ZAL
Member
Registered: 2015-04-28
Posts: 14

Re: MicroDigi beta - standalone digipeater firmware

I grabbed the new repo and compiled again (I also get pretty much the same errors as Stanley - I compiled on Debian Wheezy).

I see incoming packets being repeated (by monitoring a 2nd rig and watching the Tx LED on MicroDigi - I'm not yet transmitting on MicroDigi).
I now do not see anything on the serial line.

On a side note Mark, I see in device.h
#define OPEN_SQUELCH false

Is it OK to set to
#define OPEN_SQUELCH true
as I run open squelch.

I found this interesting circuit for running open squelch and the TNC (pretty much any TNC) set for closed squelch
http://www.ok0bez.com/files/aprs/TNC2_G … uelch_DCD/
I have most all the components, so may glue one together and see how it performs.

I'll try to do some more testing soon...

Nigel.

Offline

#7 2015-05-17 08:07:33

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Mark,

I git clone MicroAPRS, I still get the same warnings but the hex managed to be compiled...

I'll enable SERIAL_DEBUG and re-try ...


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#8 2015-05-17 09:15:45

G4ZAL
Member
Registered: 2015-04-28
Posts: 14

Re: MicroDigi beta - standalone digipeater firmware

Mark,

I get the same errors when compiling MicroAPRS and MicroDigi, however, I get no errors when compiling MicroModem

I have also tweaked my files to make the images in MicroDigi and named MicroDigi.hex etc

Nigel.

Offline

#9 2015-05-17 11:43:02

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

I'll have a look at the warnings, it shouldn't make a difference for the functionality of the firmware, but they are a bit annoying to look at wink

You can set OPEN_SQUELCH to true just fine, it will work better if you are running an open-squelch setup. Both the MicroModem hardware and software is designed to handle open-squelch operation just fine, and in fact you will probably get better performance on weak packets like that smile

Offline

#10 2015-05-17 12:04:27

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

I found the reason for the warnings. Apparently, GCC-AVR 4.7 treats atomic blocks of code differently than in 4.8, and you get these errors because some of the interrupt enable/disable code return values are statically referenced. This has changed with 4.8. It shouldn't actually make any functional difference, but it is annoying to look at. It's quite easy to update to GCC-AVR 4.8 on Raspbian Wheezy though, have a look at this site:

https://nicohood.wordpress.com/2015/01/ … pberry-pi/

You can just ignore the stuff for the Arduino IDE if you like, and just add the repository, run "apt-get update" and "apt-get install gcc-avr" and you will have v4.8.1 smile

Offline

#11 2015-05-17 13:56:44

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Mark,

Upgraded to avr-gcc to 4.8.1 and the warning all went away ...

Cont to monitor the Digi on Serial Debug ...

I changed the ADC_REF to 5V and now able to decode packets and showing them on the Serial screen ...

Last edited by Stanley (2015-05-17 14:08:36)


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#12 2015-05-17 16:13:02

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Here is something I managed to capture , not much traffic tonight ...

Why is the Digipeater PATH repeated twice ??

SRC[                        9W2SMF-9] DST[P3QTV6-0]
RXd Path (2): [WIDE1-1] [WIDE2-1]
TXd Path (2): [9W2SVT-3*] [9W2SVT-3*]

From aprs.fi raw :-
2015-05-17 23:05:43 MYT: 9W2SMF-9>P3QTV6-9,9W2SVT-3,9W2SVT-3*,qAS,9W2FTG-1:`mCjl!6j/]"4j}TRAVEL AROUND 144.390mhz=


SRC[9W2EDQ-9] DST[APOTU0-0]
RXd Path (2): [WIDE1-1] [WIDE2-1]
TXd Path (2): [9W2SVT-3*] [9W2SVT-3*]

From aprs.fi raw :-

2015-05-18 00:40:48 MYT: 9W2EDQ-9>APOTU0-9,9W2SVT-3,9W2SVT-3*,qAR,9W2RUT-2:/171640z0310.97N/10139.75Ej176/051/A=000236 14.2V 28C HDOP01.2 SATS07 LaNuN Open Tracker USB
2015-05-18 00:41:17 MYT: 9W2EDQ-9>APOTU0-9,9W2SVT-3*,9W2SVT-3*,qAR,9W2EDK-2:/171641z0310.63N/10139.60Ej242/049/A=000257 14.1V 28C HDOP02.0 SATS05 LaNuN Open Tracker USB
2015-05-18 00:41:42 MYT: 9W2EDQ-9>APOTU0-9,9W2SVT-3,9W2SVT-3*,qAR,9W2RUT-2:/171641z0310.53N/10139.35Ej258/017/A=000288 14.0V 28C HDOP01.4 SATS06 LaNuN Open Tracker USB
2015-05-18 00:42:14 MYT: 9W2EDQ-9>APOTU0,WIDE1-1,WIDE2-1,qAR,9W2RUT-2:/171642z0310.51N/10139.04Ej271/047/A=000292 14.1V 28C HDOP01.2 SATS07 LaNuN Open Tracker USB
2015-05-18 00:42:34 MYT: 9W2EDQ-9>APOTU0-9,9W2SVT-3*,9W2SVT-3*,qAR,9W2EDK-2:/171642z0310.53N/10138.79Ej286/046/A=000345 14.1V 28C HDOP01.2 SATS07 LaNuN Open Tracker USB

Last edited by Stanley (2015-05-17 17:50:50)


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#13 2015-05-17 21:59:46

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

Hi Stanley!
That seems to be a bug, it looks like the path algorithm acts on both the first WIDE1-1 and the second WIDE2-1, which it shouldn't. I'll investigate smile Thanks for spotting it!

Offline

#14 2015-05-18 03:39:15

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Here is my config.h settings:-

I'm testing the ROLE_WIDENN with max of 2 hops ...

#define DIGIPEATER_ROLE ROLE_WIDENN
#define DIGIPEATER_CLAMP_N 2

The rest are at defaults...

How is the memory usages on this Digipeater ??

Last edited by Stanley (2015-05-18 03:39:44)


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#15 2015-05-20 13:18:14

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

I've fixed the bug, plus a few others I found and pushed a new version to GitHub smile The digipeating logic is much more solid now, so give it a try and see how it works!

The memory usage is a bit large right now, at around 1700 bytes. It's not been optimized at all, so I'm pretty confident I can push this way down smile

Offline

#16 2015-05-20 20:11:45

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Dear Mark,

I installed the latest Digi firmware ...

The digi is working okay but I hv this issue :-

1. When I am nearby and Tx, I can see the Rx LED on the handy lit up but not decoded my the MicroAPRS/SVTrackR
So I pull out the Mic input to listen to the APRS sound ...

I find the sound okay but almost at the end the volume becomes softer ... so I guess the entire packet was not decoded ( but was received and decoded by further away iGates ).

Any settings can I adjust for this  ??

Here are the raw packets  ( 9W2SVT-3) is the 5W digi  :-
http://aprs.fi/?c=raw&call=9W2SVT-8

9W2EDK-2 is 24.9km away
9W2FTG-1 is 21km away

2015-05-21 02:09:51 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAR,9W2EDK-2:=0309.84N/10138.36En060/051/A=000352 Seq:44 D
2015-05-21 02:09:58 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0309.84N/10138.45En086/052/A=000349 Seq:45 H
2015-05-21 02:10:28 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0309.90N/10138.70En074/050/A=000373 Seq:46 T
2015-05-21 02:10:39 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0309.92N/10138.83En091/050/A=000332 Seq:47 B
2015-05-21 02:10:45 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAR,9W2EDK-2:>SVTrackR v1.61b 5.03V S:17 B:0 R:0 U:16m Seq:47
2015-05-21 02:11:44 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAS,9W2FTG-1:=0309.76N/10139.20En220/044/A=000276 Seq:51 H
2015-05-21 02:12:11 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAR,9W2EDK-2:=0309.59N/10139.02En250/016/A=000264 Seq:52 H
2015-05-21 02:12:39 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAS,9W2FTG-1:>SVTrackR v1.61b 5.05V S:17 B:0 R:0 U:18m Seq:54
2015-05-21 02:13:32 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0309.92N/10138.88En094/020/A=000278 Seq:59 H
2015-05-21 02:13:44 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:>SVTrackR v1.61b 5.07V S:17 B:0 R:0 U:19m Seq:60
2015-05-21 02:13:56 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0309.99N/10138.92En009/013/A=000248 Seq:61 B
2015-05-21 02:14:01 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:>SVTrackR v1.61b 5.07V S:15 B:0 R:0 U:19m Seq:61
2015-05-21 02:14:40 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0310.13N/10138.96En099/000/A=000208 Seq:63 H
2015-05-21 02:15:05 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAS,9W2FTG-1:>SVTrackR v1.61b 5.05V S:15 B:0 R:0 U:20m Seq:64
2015-05-21 02:15:11 MYT: 9W2SVT-8>APZSVT,WIDE1-1,WIDE2-2,qAS,9W2FTG-1:=0310.11N/10139.01En068/008/A=000234 Seq:65 H
2015-05-21 02:16:40 MYT: 9W2SVT-8>APZSVT-8,9W2SVT-3*,WIDE2-2,qAR,9W2EDK-2:>SVTrackR v1.61b 5.05V S:0 B:0 R:0 U:22m Seq:66


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#17 2015-05-20 21:25:37

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

Hi Stanley!
That's interesting... Is the receiving radio right next to the transmitting one? The signal coming into the receiving radio might actually be too strong, and thus causing distortion. Do you hear the packet becoming softer also when you have a speaker connected directly to the audio output of the digipeater?

Offline

#18 2015-05-21 03:36:22

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Mark,

No, the Digipeater is on the rooftop at 19th floor and I am driving on the road ... probably 200-400 meters away heading back to my place ...

I wil try to record the sound output from the Digipeater and re-play it back to the MicroAPRS for decoding....


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

#19 2015-05-21 07:21:40

markqvist
Administrator
Registered: 2014-12-01
Posts: 109

Re: MicroDigi beta - standalone digipeater firmware

Very odd! I will make some recordings from the digi firmware myself and see if I can observe the same!

Offline

#20 2015-05-22 23:16:21

G4ZAL
Member
Registered: 2015-04-28
Posts: 14

Re: MicroDigi beta - standalone digipeater firmware

Mark,

Had a little time this evening and compiled the latest firmware.
It compiles just fine now on Debian 8 (Jessie).

Quick output from my setup - serial output and not Tx'ing for real just yet (although the  board LED indicates it is Tx'ing in the right places).
It hears a lot from my current igate and digipeater wink

SRC[G6UIM-0] DST[APWW10-0]
RXd Path (4): [MB7UPN-0*] [WIDE1-0*] [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[M1ABD-0] DST[APU25N-0]
RXd Path (2): [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[M1ABD-0] DST[APU25N-0]
RXd Path (3): [MB7UPN-0*] [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[M1ABD-3] DST[APU25N-0]
RXd Path (3): [M1ABD-0*] [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[MB7UW-0] DST[BEACON-0]
RXd Path (2): [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[M1ABD-0] DST[APU25N-0]
RXd Path (2): [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (1): [WIDE1-1]
TXd Path (1): [G4ZAL-0*]

SRC[MB7UG-0] DST[BEACON-0]
RXd Path (3): [MB7UW-0*] [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[G8XST-0] DST[APTT4-0]
RXd Path (2): [G0ROZ-3*] [G4ZAL-0*]
Not digipeating

SRC[G4ZAL-0] DST[APDW11-0]
RXd Path (2): [WIDE1-1] [WIDE2-1]
TXd Path (2): [G4ZAL-0*] [WIDE2-1]

Nigel.

Offline

#21 2015-06-02 03:20:03

Stanley
Member
From: Kuala Lumpur, Malaysia
Registered: 2014-12-01
Posts: 65
Website

Re: MicroDigi beta - standalone digipeater firmware

Dear Mark,

Any latest updates or features added to the Digipeater firmware lately ??

- announce / display coordinates & icons on the map every 10 or 15 mins


Stanley
9W2SVT/ N5SVT
http://9W2SVT.blogspot.com

Offline

Board footer

Powered by FluxBB