Yes. My employers designed the chips for Broadcom.
This mode needs vewry little space - why not stay within the digitally assigned band plan rather than impacting CW or SSB portions? Digital mode - IARU Region 1 - on 20m 14.070 through 14.099. That should be plenty of room! we need to look out for JT65, PSK31 etc. calling channels though.
Yeah, they are targeted at the set top market.
That said the parts that actually matter for processing are pretty uniform across the market(they’re all mostly Arm A9/A53/A57, aside from Qualcommwho to used to build their own optimizations on top of a base Arm core). I don’t see needing to go to the VideoCore/GPU yet.
I’ve worked with pretty much all of them in some capacity on similar workloads(3D graphics and animation) so I’m really familiar with their performance profiles so I’m not that concerned yet. Part of the reason why I’m looking for people interested is we’re going to need to test it across a wide range of devices and I only have access to a couple here.
It seems like there’s enough interest. I’ll start poking around into getting the Fortran toolchain up and running with the NDK and see how far I can get with it.
I did a dry run of my portable FT8 setup in the shack just now and it all worked fine with one exception. It seems clear that I can’t rely on the laptop clock to be accurate enough on a summit without internet or GPS external reference. I watched the periodic corrections made by the internet clock and there’s too much variability, even in the controlled temperature environment of my shack. My laptop could easily lose a second or more between home and the summit. I will look at getting an inexpensive bluetooth/usb GPS receiver. Has anybody else done that? What did you use for software on your laptop to extract system time from the GPS?
Is there an easier solution I’m missing? For example is there any easy way to tie my laptop’s clock to my smartphone?
73, Barry N1EU
You could probably use something like this: https://play.google.com/store/apps/details?id=com.icecoldapps.timeserver + an ad-hoc wifi network. Would take a little fussing but should be possible.
I don’t think that will work. Windows uses UDP port 123 for NTP connection and Android can’t use that port. If you have a router you can do port forwarding but not so easy up on a summit.
I just ordered a Bluetooth GPS receiver for $23 on eBay.
Really - Double clicking the callers callsign in the left-hand [Band Activity] part of the window still changes both Tx and Rx for me.
Ladies and Gentlemen,
Just in case you missed it. WSJTX V1.8.0 has been released. This is the General Availability version. ie post rc versions. Download from your usual source.
You (Just) beat me to the announcemeny Ron!
Here’s the link I got in my email:
TYPICAL - I just updated my tablet to RC3 last night, now I’ll need to upgrade again!
Getting back to the message sequence for a moment: it seems clear that we do need to allow for sending the summit ref during the message sequence. S2S FT8 contacts will not work unless both parties can send a summit ref.
CQ G4TGJ IO93
G4TGJ N1EU FN32
N1EU G4TGJ -5
G4TGJ N1EU R-2
"This is the full General Availability release of WSJT-X Version 1.8.0.
Changes from WSJT-X Version 1.8.0-rc3 are very minor:
- Right-click on the Wide Graph now pops up a Context Menu. Select
the item Set Rx & Tx Offset to complete a one-handed setting of
both red and green frequency markers."
You could try putting the SOTA ref in message 5 and add 73. If both do that you have completed and exchanged summit info. You may have already seen the other guy giving his reference and have it on screen so you don’t need it a second time…
Yes, interesting suggestion although that would dispense with the “RRR” altogether. So there’s an implied “R” with the final SOTA ref 73 message. I do really want to limit the entire exchange to 3 xmsn’s by each party.
I set up two radios/computers side-by-side transmitting into dummy loads. It’s possible to do a 3 xmsn (each side) QSO with the last message being SOTA ref 73 but it requires the CQ’ing station to manually click on the Tx5 button to force xmsn of SOTA ref 73 as the 3rd xmsn. Without the manual click, the computer will first send the Tx4 RRR message and subsequently the SOTA ref 73 msg on the following xmsn.
73, Barry N1EU
Since FT-8 is already too easy a mode, I figured we may as well try make it easier[*]. I’ve just pushed an update to RBNHole to monitor the PSKReporter website and post spots for JT-65 and FT-8.
It is currently inert, meaning no spots are posted yet. I want to give it a bit of time to bake in with real world data. As such, if anyone is planning an FT-8 or JT-65 activation over the weekend, could you let me know via a PM here so that I can monitor to see if you would have been spotted. If I’m comfortable it’s no spammier than RBNHole, I’ll make it live.
Same rules as per RBNHole, need to have an alert posted, frequency lockout within 2.5kHz, time lockout with 10 minutes between spots, same window (-1/+3).
Other data modes could conceivably be added too, of course. We should also perhaps consider changing the name to either Automatic Spot Submission Hole (for US folks) or Automatic Reporting of Spots, Etc, Hole (for the Commonwealth folks). I like naming things after myself
[*] Actually, I’ve been thinking about it on and off since Ed suggested in earlier in the FT-8 threads.
HamAlert and FT8 spotting
Hi Andrew, I got the meaning of the abreviation of the words used but my proposal would be to change the name from RBNHole to RyanSpot - to reflect the fact that you are putting so much work into it.
I’m not even remotely that narcissistic, Ed, but I appreciate the sentiment.
SOTAref (without slashes or dashes) space RR73
The RR73 is an accepted standard ending of a QSO. If the SOTA ref is longer than VK3VC001 then dropping one R should be OK.
Of course if we had some extra bits in the message then the FT8 MT could do something to help. I think that the best we could hope for at present is to be able to send CQ VK3AFW SOTA QF22 but that depends on whether the guys have something else in mind for the currently unused bits associated with the grid square coding.
There is a good argument for ranking modes in order of ease of use as follows:
Phone - FM, SSB, Digital voice, AM. Good when signals are good.
CW- as simple as phone once you have learned the language. Good when signals are weak. Simplest gear.
Digital Modes, including FT8. Fast decision making sometimes required, contains some typing and other computer use skills. Good when you can’t hear any signals. Most complex gear.
As with most things, you get back in proportion to what you put in.
I don’t understand Ron - how can you transmit 19 chars? I thought 13 chars was the limit.
73, Barry N1EU