APRS – Making it work

Konrad_Roeder · 2018-05-11T01:55:02.253Z

OK … I can query the DreamCatcher’s APRS API with Node-RED code. Now, I need to figure out how to parse out the call signs out of the text.

Screenshot from 2018-05-10 18-48-16.png1278×695 126 KB

The first node is essentially a button that starts the process.
The next node makes the HTTP call to the API which returns a JSON data structure
The JSON node takes the JSON data structure and extracts the text.
The msg.payload dumps the output of the JSON node into the debug window, which you can see on the right.

On the left is a palette full of Node-RED functions that can be used to process the data.

–Konrad, WA4OSH

ac8dg · 2018-05-11T02:18:35.188Z

I’m not great at the network stuff.

Can two devices connect to the dreamcatcher at the same time? For example on my wifi network, can one computer run skylark ui and a second computer interrogate the dreamcatcher with the getAPRS ?

Konrad_Roeder · 2018-05-11T02:26:24.647Z

Yes. You can browse what’s on your dreamcatcher on one window and make queries on another window.

Here’s my DreamCatcher through the web interface you are familiar with

Screenshot from 2018-05-10 19-20-52.png1276×696 795 KB

Here’s a command line querying my DreamCatcher

Screenshot from 2018-05-10 19-22-46.png1279×698 571 KB

and … developing Node-RED code in yet another session that is also querying my DreamCatcher.

Screenshot from 2018-05-10 19-24-00.png1278×695 85.8 KB

Cool, eh?

–Konrad, WA4OSH

Konrad_Roeder · 2018-05-11T03:23:52.863Z

I answered your question for multiple sessions in one computer as yes.
The answer for multiple computers looking at the DreamCatcher at the same time is also yes.

One DreamCatcher can serve maybe a 5-15 people using laptops or tablets over Wi-Fi.

–Konrad, WA4OSH

Konrad_Roeder · 2018-05-11T04:47:24.549Z

Screenshot from 2018-05-10 21-21-01

Screenshot from 2018-05-10 21-23-54

Note that the most recent message is on top, but I don’t have any idea when it was sent.

Screenshot from 2018-05-10 21-28-46.png745×68 16.5 KB

Note that KE7WWT’s messages are malformed. The OUTNET “callsign” is not padded on the right with spaces as required by the standard. Outernet should probably not forward mal-formed APRS messages.

Screenshot from 2018-05-10 21-44-40.png819×633 87.6 KB

OK here’s my NodeRED script … it parses through the JSON data structure looking for the : which is the beginning of the TO call sign. I still have some work to do. But it’s almost impossible to know if I’ve seen a message already without a date-time code included in the JSON record.

Screenshot from 2018-05-10 21-31-08.png1262×612 77.9 KB

–Konrad, WA4OSH

clavo · 2018-05-12T05:40:14.176Z

Question. Not sure if this has been answered before… but for a message to get picked up and sent through Outernet, does the word ‘outernet’ need to be capitalized? Thx.

–liam

Abhishek · 2018-05-12T07:20:55.332Z

“OUTNET” and yes, needs to be in all-caps.

Edit: by request, “outnet” (all smalls) works too, now.

kb2sdrjay · 2018-05-12T10:47:17.615Z

Perhaps that should be added to the user manual?

kenbarbi · 2018-05-12T11:17:17.422Z

Konrad is going to work on a separate Apps Manual, and should add it. Ken

Konrad_Roeder · 2018-05-12T13:43:19.248Z

I will definitely will be working on the Apps Manual. APRS is definitely a section that I’m going to cover.

–Konrad, WA4OSH

ac8dg · 2018-05-12T23:27:23.833Z

While “one-way” transmissions are not really allowed… I have proved you can send an aprs message to callsign OUTNET and if picked up and sent into the aprsis system it will be captured and re-transmitted.

But I should follow the rules and at least send it to ourselves as a “valid callisign”

Sending to OUTNET is probably the “extreme” of third party traffic

aprs to outnet.PNG1158×619 625 KB

Konrad_Roeder · 2018-05-13T01:21:18.693Z

Jim,
First of all, APRS is a one-way transmission. It falls under telemetry in FCC part 97.

This is well known and it’s part of the standard. Look in section 4 Destination Addresses.
OUTNET padded with three blanks is a valid destination in APRS. There are actually quite a few like those.

This station is actually using OUTNET as a source call sign:

Screenshot at 2018-05-12 18-09-20727×45 5.19 KB

And, the APRS system accepted the message. It shows the source is in Corvallis, OR.

But Outernet should not be accepting malformed packets. Everything in red is malformed:

https://aprs.fi/?c=raw&call=KE7WWT*&limit=50&view=normal

Screenshot at 2018-05-12 18-20-181009×345 91.7 KB

References:
FCC Part 97 Regulations
APRS Standard

–Konrad, WA4OSH

Konrad_Roeder · 2018-05-13T15:48:02.960Z

Using the existing API, which returns the 50 or so most recent APRS messages, without any idea when they were sent, we can get the 5000 character-long “result”, split it into individual messages (looking for the \n), and then stuff everything into a workable JSON structure using a parser. Then the applications can look at the elements in the data structure and do various things like notify the user that an APRS message came it, flash lights, forward the packet to some other network (Twitter or Email could be examples), etc.

Here’s what the Node-RED flow will look like for an APRS twitter bot.

OuternetAPRSTwitterBot.png748×410 34.1 KB

There’s still a couple of issues.

We need time stamps to know when the messages were received. Do you want to act on old messages or act more than once? A stitch in time saves nine.
We need to find a parser that will accommodate both uncompressed and Mic-E formats and is known to be pretty error free.
The current API can only return a fixed number of records.

It sure would be nice if a real API was provided that returned a useful JSON structure instead of this pathetic mess of a giant character string without time stamps.

–Konrad, WA4OSH

Konrad_Roeder · 2018-05-13T16:00:47.983Z

Here is an APRS parser written in JavaScript that might just do the trick:
npm-aprs-parser

I will see what it will take to wrap it inside of a Node-RED node.

–Konrad, WA4OSH

ac8dg · 2018-05-13T16:19:33.587Z

Konrad_Roeder:

do various things like notify the user that an APRS message

Could this be ported to a arduino feather or esp32

adafruit.com

Adafruit WICED WiFi Feather - STM32F205 with Cypress WICED WiFi

Discontinued - you can grab Adafruit HUZZAH32 – ESP32 Feather Board instead! Say "Hi!" to the WICED Feather! Perfect for your next Internet connected project, ...

Price: $34.95 USD

or the email alert thing I use
https://www.pixeltwenty.com/espalert.html

I don’t see outernet changing the standalone-robust sklyark OS, but a second cheap board w/wifi could do a lot.turning on lights, sms or email.

Konrad_Roeder · 2018-05-13T17:02:53.540Z

Node-RED needs an operating system to live on, and it needs a little more horsepower.

Arduino has no operating system; it’s not that much of a processor
Although ARM-Cortex (STM-32) can run simple real-time operating systems, it’s still not running the bare minimum.

Don’t you want one of these? Raspberry-Pi Zero (very low-cost).
Node RED on Raspberry Pi zero

–Konrad, WA4OSH

ac8dg · 2018-05-13T17:20:15.531Z

I guess the rpi-zero (the latest with the wifi built in) would be a choice. I had bad luck with add on usb boards that “friction” fit the pins on the zero. I think they have sorta improved that.

My latest board is the STM32L476RG with the “drag and drop” update capabilities.
You just connect the usb and it is seen as a drive. Then drag / drop the compiled bin code and on next restart it is updated. how simple could that be.

Granted you have compile the mbed code or have someone else do it…

Konrad_Roeder · 2018-05-13T17:38:23.066Z

Node-RED is even quicker. You open up a web-browser to 127.0.0.1 (the loop around address), develop and test.

The Pi Zero has a 40-pin HAT connector so you can develop a HAT board or connect directly to the pins.

–Konrad, WA4OSH

clavo · 2018-05-15T05:13:05.131Z

Yep. That was me pushing that OUTNET as a callsign to test… That, along with 98% of the other traffic shouldn’t been in that downlink feed…

-liam

Konrad_Roeder · 2018-05-19T12:02:50.483Z

@Abhishek @ac8dg @kenbarbi @Syed

During this last week, I worked with some Node-RED experts to get us a parser for APRS. It takes a raw text file and parses it into a JSON structure. Using simple constructs, the elements can be examined and used for all sorts of APRS projects on Outernet – receiving APRS messages and acting on them.

The APRS node in blue can be used to read APRS messages, location and weather out of the APRS-IS database, given a call sign.

The new parser node will allow us to parse APRS text data into a JSON file. From that, we should be able to receive APRS messages, location, weather, telemetry data, etc.

Screenshot at 2018-05-19 04-55-56.png710×383 24 KB

But I have an important feature request: TIME STAMP PLEASE I need to know if the text I’m looking at is new or an old record. Could you please add a field to the DIRECT/getTunerStatus that returns the data file name that it was extracted out of? We can extract a timestamp out of that file name and know if we have a new or old message.

JSON naturally ignores new fields. If there is an existing JSON parser that is reading the JSON object created by DIRECT/getTunerStatus, and there’s a new field, it gets ignored. This means that with JSON there does not need to be a strict contract between the source and destination of the object. (unlike XML).

–Konrad, WA4OSH