I think there’s a lot of interest. I think there’s also concern that a smartphone might lack the necessary horsepower.
There’s people running WSJT-X on a Raspberry Pi 3 which is around the umph of a midrange smartphone so I’m pretty sure it’s do-able.
It’d be pretty straightforward to run some decoding at initial setup and let the user know if their phone has enough power. Worse case nearly every phone has a GPU on it and most of them support OpenCL or some variant.
The sigproc code is in FORTRAN but GCC for ARM should compile it. The probs being whether the ARM port of GCC FORTRAN is at the same level as the x86 port. Everything else is just normal PC GUI/app stuff which you would want to rework to use a phpne,/tablet anyway.
Well it’d have to be considering the linux-armv7 variant runs just fine on a RPi.
Anyway, I’m happy to talk details offline, I’m more curious about general interest. It’s not a trivial amount of work to bring it over but if there’s a use for it I’d be happy to dig in more.
I suppose this shouldn’t surprise me, as it was still very much an issue at the last big company I worked for less than a decade ago. Still, even then there was a serious effort being made to get as much of the core sigproc code into a language that worked better with the rest of the system…
there is already an Android app for JT65, and it is free
You may get in touch with the author of that one, maybe he is already working on an FT8 version ?
I surely would be interested in such an app, because now I have to drag along an extra Windows tablet for digimodes. It would also solve all the Ctrl-Alt-Shift keys needed …
73 - Luc ON7DQ
I have had quite a lot of LoTW confirmations - but more would be nice
OK Got it!
It was logged on the SOTA database
This sequence wouldn’t work with the auto sequencing because that turns the transmit off after the 73.
What we need is a two letter code in the CQ that means SOTA. For example perhaps we could do this:
CQ ZZ G4TGJ IO93
G4TGJ N1EU FN32
N1EU G4TGJ -5
G4TGJ N1EU R-2
G4TGJ N1EU 73
We’d know that CQ ZZ (or whatever we choose) was for SOTA and so would be expecting the summit reference. My only concern with this is that non-standard messages can confuse WSJT-X and it logs the wrong callsign. This might also be an issue with the slash in the reference - this might be interpreted as a callsign modifier.
If this IS a concern, perhaps an option could be provided to narrow down the spectral decoding bandwidth (i.e., more focus on the tx/rx frequency) to decrease the processing load.
I’d certainly be interested in an Android version of FT8. I’m also concerned whether my phone would be powerful enough but it is a good point about the Raspberry Pi since it uses a mobile phone SoC. I’m also a professional software engineer so could help.
If we chose our own SOTA FT8 frequency this would help too.
Do you mean other than e.g. 14.074 or do you mean a SOTA offset within 14.074?
No. It uses a set-top box SoC.
Hi Richard - have you tried the suggested format? I suspect you may have a problem with the slash “/” in the third SENT message as in the background scripting language in WSJT-x can interpret this as an end-of-message symbol and wont send the NP022 RRR at all.
I “think” the ONLY message that can take special characters is the free form message which is the one you can change in settings and may be the fifth SENT message?
Maybe I have the message number wrong in your example - but using / has caused me isses on a couple of occasions.
It would have to be a frequency other than 14.074 because you couldn’t guarantee that any particular offset within that was free.
Are you sure? The original Raspberry Pi definitely used a mobile phone SoC.
I haven’t tried that format and I agree that the slash might be a problem.
I think for 20M, somewhere between 14.065-14.069 would work. I like this idea, especially because these will be momentary operations on this non-standard frequency and will only last a few minutes. But I suggested this previously in the thread and it was mentioned that this would be in violation of the voluntary bandplan allocating 14.000-14.070 for cw.
The downside to this would be that you would be dependent on FT8 chasers seeing your SOTAwatch self-spot. I may try this on Saturday before moving up to 14.074
I certainly wouldn’t want to go below 14070. There’s no reason we couldn’t go up in the SSB section since FT8 should work despite any interference. Of course there isn’t actually an SSB section as it is the all modes section. At least that’s what it says in the RSGB band plan.