Right then, it’s time to give this another go and see what happens!
I worked 4O, OK and EA on a flat band last time, so who knows? All rather exciting - apart from the lounging around doing nothing for interminable periods of time that is.
5w, FT-817, SOTABEAMS SB6 Moxon, Samsung Galaxy S2 phone running JT65android, WolphiLink interface.
Bobbins.
JT65android only started decoding 5 minutes before my scheduled pack-up time (because I’ve got a gig in Rawtenstall tonight - a place I’d never heard of before the first time I set out to activate G/SP-009 back in 2003…).
I managed one 6m JT65 QSO - with G0JEI in IO93, to add to the two 2m FM QSOs with 2E0LKC and 2E0LMD.
Not sure why it took so long before starting to do any decoding. Annoying, as 50.276MHz was rather busy with JT65 signals.
It is possible that the second sentence provides a clue that may be the answer to the question.
I had a play with JT65android on my old MotoG (quad core A7 1GHZ CPU). That should knock spots of a Galaxy S2 in performance terms. Trying it back to back with my Linx1010 running WSJT-X using speakers and mics was appalling. It didn’t decode a lot of the time and it sent mince data to WSJT-X.
It was so diffiicult to use JT65android with no waterfalls and visual feedback, and when it worked, performance was so iffy. I don’t believe that it’s a viable solution. If it is a pain to make it work in the calm of the shack, doing this on a hill is a non-starter.
I suggest you try a different device and/or different software.
I plan to try both different software and a different device.
However, my solution is viable, as I have already completed several successful JT65 SOTA activations with the set up. There are areas where it can be significantly improved - which is what I’m looking at now.
The concept of a “waterfall” is surely a misnomer with weak signal modes?
You can see a spectrum and waterfall captured using SDRsharp in that article.
The problem is that with weak signal modes there are still plenty of things being received and attempting to decode, that are too weak to show up on any waterfall.
The waterfall is a graphical display of the energies in each frequency bin resulting in the FFT of the sampled stream. Whether the demodulation code uses an FFT or not, no energy in a bin means no energy detected means no signal to decode.
You may be confusing the limited dynamic range that can be displayed using brightness and colours. That can result in the user selecting the “brightness” so that strong signals do not “washout” the display and weak signals are not displayed. If the dynamic range of the input is say 60dB and the waterfall only has 40dB of display range, then setting the display so the biggest signal produces the max brightness will mean signals in the 0 to 20dB range being invisible.
Solving this problem is difficult, it’s why you have accumulate modes so the signal on the waterfalls are time averaged so weaker signals stand out more. This code is very CPU intensive and so sucks the life out of your phone battery quickly and is missing from lots of phone apps for this reason.
…so what I said then…?
No Tom.
The waterfall is a way of visualising what is being received. It’s like looking at a digital picture. My screen is 1920x1200 = 2.3megapixels and if I view a photo from my camera at 14megapixels, it gets downsampled and averaged to fit the screen. The fine detail is there if I zoom in but not visible when I squeeze 14mp onto a 2.3mp screen. (If it was CSI I could keep zooming in forever to show the perp committing the crime!).
A waterfall is the same, downsampled/averaged to fit the whole band to the pixels available but there’s nothing to stop me (in principle) zooming in to see those weak signals.
Have you tried the new FT8 mode yet? It uses 15 second periods and a QSO can be completed in 1 minute 15 secs.
There is the possibility of a 13-character plaintext transmission which could contain your SOTA reference if desired.
It is almost as efficient as JT65, but it is about 6 dB less sensitive. The bandwidth of an FT8 signal is 55 Hz. There is a huge amount of activity … at least as much as JT65.
73,
Walt (G3NYY)
No. I cannot imagine that my phone’s processor would come anywhere near close to coping with that - and that’s if anyone ever develops an Android app for FT8 - which seems unlikely really.
I’m tempted to update my kit so that I can operate these modes via WSJT-X on an activation.
Curious to test the veracity of your statement I carried out some tests this evening. Using all the processing available on the waterfall to look at WSPR signals I concluded that on a typical cycle I could see about 2/3rds of the signals (it did vary but I never managed to see them all). JT65 would be much harder as some the signals often overlap. While you may be right in principle, I concluded that Tom was right in practice.
I think that the waterfall (as implemented) would struggle in both the frequency and the time domain to be able to show all the signals. It could be done of course but it would add no value to the operation of JT65 I think.
W6PNG is having a lot of success using a small (1 kg) Windows 10 notebook for FT8 activations.
Walt
Oh, I don’t know, Tom. If you speak nicely to 'FMF I’m sure he would be pleased to write one for you. The source code is in the public domain. 
Trivial … I think that’s the usual expression.
73,
Walt (G3NYY)
Oooo! No! Far too much like work that. I have to deal with chip companies and their (flaky) Android ports on an almost daily basis in my job. I certainly don’t want to port stuff to Android after a day of dealing with it in the office.