First tests receiving data with using 'LibAPRS'

DJ7OO · 2015-01-02 19:57:54

Hello Mark and all and best wishes for 2015,
today i did make some first tests using library 'LibAPRS' and test program 'Basic_usage'. There seems to be no problem with its transmit functions, but at first receiving any incoming data did not work at all. My hardware was board ARDUINO 'UNO' and problem was caused by a missing connection between input 'AREF' and 3.3V power supply point. After this had been solved, i could decode data coming out of FM receiver tuned to 144.8 MHz. Below are some receiving samples:

Received APRS packet. Data: > FM Relais 438,775MHz
Received APRS packet. Data: `~C9qI8>/"5q}Ralf.F07
Received APRS packet. Data: `}LTq C>F`"5U}_"
Received APRS packet. Data: `}`'l+[v/>"4;}=
Received APRS packet. Data: `~M)npa>/"69}
Received APRS packet. Data: `~F|l >/`"5z}_"
Received APRS packet. Data: `~Fel >/`"5q}_"
Received APRS packet. Data: `~ODn]1>/"6D}
Received APRS packet. Data: > www.aprs-frankfurt.de .
Received APRS packet. Data: `~OUpSC>/"6C}
Received APRS packet. Data: `~R7p>d>/"6[}Ralf.F07
Received APRS packet. Data: `~DHl >/`"6&}_"
Received APRS packet. Data: <IGATE,MSG_CNT=5,LOC_CNT=32
Received APRS packet. Data: `~`(l!7j/"8i}
Received APRS packet. Data: `~Chl >/`"5\}_"
Received APRS packet. Data: !5007.86
Received APRS packet. Data: <IGATE,MSG_CNT=5,LOC_CNT=32
Received APRS packet. Data: `~`(l!7j/"8i}
Received APRS packet. Data: `~Chl >/`"5\}_"
Received APRS packet. Data: !5007.86
Received APRS packet. Data: `~Bcl >/`"5:}_"
Received APRS packet. Data: `~C`l >/`"5_}_"
Received APRS packet. Data: db0sif.darc.de=271,LOC_C
Received APRS packet. Data: `~C`l >/`"5_}_"
Received APRS packet. Data: `~CXl >/`"5T}_"
Received APRS packet. Data: `~CLl >/`"5M}_"
Received APRS packet. Data: `~Bcl >/`"5:}_"

Its looking like mainly only parts of MIC-E compressed data will be decoded, so there still seems to be a problem within the library. Later of course, it also would be nice, in case there would be a way for also selecting between decoding e.g. APRS source and destination data.

Unfortunately while doing those tests, 'Basic_usage', program did crash quite often. After this happened, the RX-LED did stay running continously and i was forced to push the RESET button. Because of this, i also did try to use both open and closed squelch mode, but problem always was same. Maybe Mark or somebody else has an idea, what the reason could be.

73 de Klaus, DJ7OO

markqvist · 2015-01-03 16:58:10

Hi Klaus!
Thanks for these tests! Right now there is still no MIC-E decoding, so all packets will be the "raw" data in the info field! Source and Destination fields are actually decoded, but maybe I forgot to include how to get the info in the example! Oops! I will make an update with the info included on how to read these fields from the packet, it's very easy

I will also include MIC-E encode and decode, but I haven't had time to read up on the compression format yet, so right now I have no idea how it works It should be no problem to implement it though, just need to understand it first

markqvist · 2015-01-03 16:59:42

And yes, if you select the 3.3v reference, you need to actually give the AREF pin 3.3v as you say. If you select 5v reference no connection is needed, it will use the internal reference I guess I should point this out clearly in the example!

DJ7OO · 2015-01-03 18:54:11

Hi Mark,
thank you for answering. Making code for decoding MIC-E isn't a big problem. Here especially reading
http://www.aprs.org/doc/APRS101.PDF
could help a lot, but in case at least those SRC, DST and DATA ( like known from MicroAPRS ) would be provided by library, users also could make their own MIC-E decoding if required.

Mark, do you have an idea about those program crashings?

markqvist · 2015-01-05 21:50:06

Thanks for that! I actually have the entire APRS protocol reference printed out in a nice binder I had just forgotten that the MIC-E format was also covered in that! Beautiful!

I'm sorry I haven't gotten round to looking at the crashes and updates yet, but the start of the new year has been very busy, and then I caught a nasty flu to top it off, so I have been a bit "slower" than usual with everything I will get to this very soon!

markqvist · 2015-01-05 21:53:57

Btw, could you post the exact sketch you're using here??

markqvist · 2015-01-05 22:39:05

Okay, the library was not actually adhering to the ADC reference and open squelch settings That is fixed now! Try having a look at the new version I just pushed to GitHub. There is also examples on how to get DST and SRC callsign and SSIDs! I will leave the sketch running all night now, connected to a radio and see if it crashes

Stanley · 2015-01-06 03:28:23

Dear Mark,

In case u missed this ...

The mic-e encoding/decoding codes from ArgentRadioShield Library by WA5ZNU, modified by DB1NTO to work with MicroAPRS ...

I'm using this libs for ver 1.1 of SVTrackR and it is working good ...
https://github.com/stanleyseow/ArduinoT … /MicroAPRS

I'll port my SVTrackR codes to use LibAPRS in the future ..

BTW This is different from the "Arduino IDE version" of MicroAPRS codes, right ?

DJ7OO · 2015-01-06 10:15:46

Hi Mark,
great, i will test new library version next days and report.

BTW: Yesterday i did make a first program for converting MicroAPRS serial data into standard APRS format. This also is including data send in MIC-E format. Resulting data strings are for use under W2APRS. Because my Smartphone does not support Host Mode, i had to make the connection via Bluetooth, but after some starting problems meanwhile this is working fine. Nevertheless software still needs i little bit of optimizing and a future version with using LibAPRS of course could be a next step.

73 de Klaus, DJ7OO

DJ7OO · 2015-01-06 12:37:50

Hi Mark,
your updated LibAPRS and its new basic_usage program is decoding like a charme.
Below see some first samples ( where i did remove the additional headers ):

SRC: DB0ZUS-0. DST: APNU19-1. Data: ;438.625- *111111z4823.98N/01035.92ErDB0ZUS -> Multimode,EchoLink,SSTV
SRC: F4CWZ-9. DST: TX4RP3-0. Data: `|`/m}Ea/"7\}
SRC: DB0MI-0. DST: APNU18-0. Data: > www.aprs-frankfurt.de .
SRC: F4CWZ-9. DST: TX4RQ1-0. Data: `|`(o-Ha/"7^}I driving ambulance: Working
SRC: DB0UT-0. DST: APUD19-0. Data: !4944.99N100707.11E# APRS FILL-IN DIGI DB0UT
SRC: DB0IDS-0. DST: APNU19-0. Data: !5013.22N100814.89E#PHG2330/W1-1 Digi Idstein/Ts. F22, 420m NN
SRC: DB0GKM-0. DST: APNU19-2. Data: !4825.49N100909.05E#PHG2140 FILL-IN Digi Goenningen.
SRC: DL1IFW-7. DST: 4XUSS3-0. Data: `~Del!]>/`"6z}145,650Mhz Pforzheim Micha _
SRC: DH5FB-9. DST: APC102-0. Data: @061122z5125.27N/01214.75Eu282/045
SRC: DB0RO-0. DST: APZ186-0. Data: !4914.05NL00802.56E#PHG2740 W4,RP APRS DIGI OV Landau/Pfalz K14
SRC: DG3IC-9. DST: TY0XW5-0. Data: `~_Gq!M>/
SRC: DB0XIN-0. DST: APU25N-0. Data: =4956.81N/00827.06ErAPRS I-GATE Nauheim {UIV32N}
SRC: DF0HR-0. DST: APRS-0. Data: >anyfrog + TH-D7E
SRC: DF0HR-0. DST: APRS-0. Data: >anyfrog + TH-D7E
SRC: DG4IAK-5. DST: APOTC1-0. Data: >Temp. in HD-Wieblingen 11.9V 11C
SRC: DG4IAK-5. DST: APOTC1-0. Data: !4925.24N/00838.46E_.../...g...t036OD1w
SRC: DB0IBM-2. DST: ID-0. Data: W2,DERP7 APRS Digi DB0IBM, Mainz (SysOp DJ9PZ)

Now also all data are available, as being needed for MIC-E decoding and also making a program with format conversion for use with e.g. W2APRS no longer is a problem.

Thank you for providing this. It's an enormous progress.

73 de Klaus, DJ7OO

Last edited by DJ7OO (2015-01-06 12:47:18)

markqvist · 2015-01-06 21:44:31

Great to hear Klaus! Thanks a bunch for testing it out! Today I finally got it to crash as well. After a little more than 10 hours of running, the sketch crashed with the RX LED just constantly on.. I am investigating what's going on and have a few ideas, but I haven't found the culprit yet. I'm suspecting that this is a memory access conflict of some sort, but not sure yet. This is going to be an interesting one to figure out I will keep you updated when I figure something out!

DJ7OO · 2015-01-12 15:11:16

Meanwhile i have made several also long time tests with using LibAPRS. I will not say, there was no program crash at all any more, but it's occurances were very very seldom. So in practical use it's no more a real problem. In worst case, in case RX LED remained ON constantly ( after e.g. running without problems for several hours ), program only did need restarting.

markqvist · 2015-01-13 08:28:33

Thanks a lot for testing out as well! That's good to hear. But I think it needs fixing I just haven't found the cause yet! Will hopefully have a solution soon.

markqvist · 2015-01-18 18:08:18

Ok, I think I have fixed this one now. I have just uploaded a new version to GitHub, you're welcome to try it out!

DJ7OO · 2015-01-19 18:54:38

Great to hear, Mark.
I will need another few days until i can test new version of LibAPRS, but after this i will report.

Klaus

markqvist · 2015-01-20 11:24:19

Thanks a bunch!

Knofl · 2015-01-24 23:06:18

Hi Folks,

first Tnx to Mark for sharing all this! I also made first tries with libAPRS, exclusively for receiving packets and sending it to APRX on a Raspberry. I think there is some issue left with the received paths.

I use incomingPacket.rpt_list[x].call and incomingPacket.rpt_list[x].ssid in a while... loop, and add the values to a string for formatting it in TNC2 format. Especially on repeated packets (they consist of the callsign-ssid and a "*" libAPRS seems to insert unknown characters of variable length, some binary stuff, also blanks which I concat in my code (see below).

Nevertheless, of course APRX and any other iGate software doesn't accept packets with incorrect paths and just throws it away. It's working on about 50% of the incoming packets, but unfortunately I'm losing the other 50%.

Code excerpt:

while (iCounter < incomingPacket.rpt_count)
{

sHeader.concat(String(","));
sTemp = String(incomingPacket.rpt_list[iCounter].call);
sHeader.concat(sTemp);
if (incomingPacket.rpt_list[iCounter].ssid)
{
sHeader.concat(String("-"));
sTemp = String(incomingPacket.rpt_list[iCounter].ssid);
sHeader.concat(sTemp);
}

iCounter++;
}

Any idea? I did use the microAPRS firmare before, but it decoded a lot of strange characters in my packets and I had to put it offline. And, with libAPRS it's just so much more powerful :-)

Mny tnx,

Reinhard

DJ7OO · 2015-02-09 14:50:12

Hi Mark,
i have a simple question:
Does LibAPRS prevent outsendings as long as receiving channel is occupied?

73 de Klaus, DJ7OO

Unsigned.IO Forum

#1 2015-01-02 19:57:54

First tests receiving data with using 'LibAPRS'

#2 2015-01-03 16:58:10

Re: First tests receiving data with using 'LibAPRS'

#3 2015-01-03 16:59:42

Re: First tests receiving data with using 'LibAPRS'

#4 2015-01-03 18:54:11

Re: First tests receiving data with using 'LibAPRS'

#5 2015-01-05 21:50:06

Re: First tests receiving data with using 'LibAPRS'

#6 2015-01-05 21:53:57

Re: First tests receiving data with using 'LibAPRS'

#7 2015-01-05 22:39:05

Re: First tests receiving data with using 'LibAPRS'

#8 2015-01-06 03:28:23

Re: First tests receiving data with using 'LibAPRS'

#9 2015-01-06 10:15:46

Re: First tests receiving data with using 'LibAPRS'

#10 2015-01-06 12:37:50

Re: First tests receiving data with using 'LibAPRS'

#11 2015-01-06 21:44:31

Re: First tests receiving data with using 'LibAPRS'

#12 2015-01-12 15:11:16

Re: First tests receiving data with using 'LibAPRS'

#13 2015-01-13 08:28:33

Re: First tests receiving data with using 'LibAPRS'

#14 2015-01-18 18:08:18

Re: First tests receiving data with using 'LibAPRS'

#15 2015-01-19 18:54:38

Re: First tests receiving data with using 'LibAPRS'

#16 2015-01-20 11:24:19

Re: First tests receiving data with using 'LibAPRS'

#17 2015-01-24 23:06:18

Re: First tests receiving data with using 'LibAPRS'

#18 2015-02-09 14:50:12

Re: First tests receiving data with using 'LibAPRS'

Board footer