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.
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?
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.
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.
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.
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.