Other SOTA sites: SOTAwatch | SOTA Home | Database | Summits | Video | Photos | Shop | Mapping | FAQs | Facebook | Contact SOTA

DroidPSK and HF APRS

I tried DroidPSK for the first time and got a peak activated pretty easily on 20 m. Now I am wondering about spotting on HF APRS using DroidPSK. I have been reading articles on what frequency to use, mostly on 30 meters, but I am still not sure what dial frequency I should be on here in North America. I haven’t been about to get spotted on APRS.fi using this method, so I don’t know if I am using the wrong frequency, or if I am just not reaching anyone who is receiving/gating my signal?

Anyone have success with spotting using DroidPSK?

Will

Can DroidPSK generate 300 baud ARPS messages and beacon packets?

Maybe this page will help?

How many RX gateways are out there?

Just a though: It would be interesting if APRS over HF could be integrated to the RBN stations already listening (with mostly SDR RX) ? @VK3ARR
This would make availability of gateways a big advantage.

Curious to try this.
73 Joe

DroidPSK does generate a 300 baud aprs message with the PSK63 setting. I don’t think it would need to go to the RBN, as a spot could be sent to APRS2SOTA, but it does seem like an RBN receiving station could also run APRS messenger

That was my though. I am not sure how to find out if there are enough APRS HF Igate available to pickup the signal.

I was looking at the “APRSdroid” project. That is opensource but currently does not support 300 baud. But there is an open ticket asking for this feature.

Best case scenario would be to type the message text in the phone (with APRS2SOTA as receiver) and generate the AFSK encoded APRS/AX.25 audio snipped on the phone. Then just play it and just hold the mic to the phone speaker.
I don’t need the return path. Fire and forget.
If the pile up starts you know the spot went thru.

Or modify this project:


e.g. for a ESP32 with WIFI module (webinterface to set the message) and a speaker (with LP filter).

The number of igates might be a problem. From what I have been reading, APRS Messenger was the program to use to receive and gate, but I just tried downloading it and the site says it is obsolete as it is not compatible with Windows 10. The site recommends using JS8CALL for HF APRS beaconing, but JS8CALL isn’t available on Android

Maybe a Raspberry PI version (if it exists) and use your Android phone as a VNC terminal?

I have an old W10 tablet and was looking at a faster replacement. Has to be W10 because of some software I want to use. But, and I feel the dark force of Intel/MS here, small light W10 devices have a pish spec and are limited in RAM, storage and CPU horsepower. Anything with some decent power is big, heavy and silly expensive when you consider how much grunt a modern 8 core phone CPU has. Bloody marketing people and the market segmentation ideas :frowning:

1 Like

Indeed JS8CALL with a USB GPS dongle would work for a position report. And you can message over APRS to APRS2SOTA.
All that would work on a Raspberry Pi with VNC to controll on the phone or tablet.

Still a bit sad that nobody has ported FT8/JS8CALL to Android. I guess there is something a bit odd that makes is complicated. My guess would be the fortran libraries still in use (but I might be wrong in that).

Is all the code in the libraries in FORTRAN or is there some in some flavour of Intel SIMD inline assembler? That would be a good reason to limit porting to ARM64 ! Maybe the switch to ARM for Macs etc. may provoke someone into porting it.

Joe K1JT wrote all the original programs in Fortran. I expect that a lot of the core stuff is still in Fortran if not all of it. I gather there is no Fortran compiler that translates to Android machine instructions. Is that a project for lockdown Andy/Andrew/?

Nah, GNU Fortran which is part of gcc will compile FORTRAN and you select the ARM backend for code generation. That’s the glib answer. There are tools but there’s always lots more than just having tools to porting these things.

Thirty odd years ago my employer’s code tended to contain #IFDEF blocks to deal with things that didn’t quite work the same on different architectures. I remember the chaos that ensued when one bright FORTRAN programmer (from the Research department) decided to use hexadecimal representations to code up blocks of floating-point constants, and didn’t wrap the blocks appropriately. His code compiled just fine on Sun, Vax, IBM, Convex, etc… The code even ran without complaining. The answers it produced, however…

Oooooo, respect there Rick.