Ok… so HOW many times am I going to stare at a rather inactive fldigi screen after forgetting to turn the SignaLink box on!!
I managed to decode some Feldhell tonight after scrabbling about for the document showing what various data modes look like. It’s a strange mode!
Unfortunately the Spanish station sending it could not receive me so no QSO, but now at least I know what to look for. It takes me back to when I was interested in telegraphy systems as a kid, some decades ago now, but I’d never seen it in any form of action – represented by computer now rather than the machinery of old. Mind you what’s to say the Spanish station does not have said machinery!
There’s a whole bunch of info over at https://www.nonstopsystems.com/radio/hellschreiber-function-operation.htm
I noticed just now that the Raspberry Pi that runs my ADBS receiver and also has ‘1-Wire’ temperature sensors for the central heating registered a pipe temperature of a theoretically impossible -1700C.
Oh, did I mention that my 20m / 6m dipole is in the loft… and the Pi is in the loft… about 2 feet from one leg of the dipole… Hmmm. I can see a connection here given the timestamp was the same as a JT65 transmission.
I noticed today that the BBC uses bbc.in as a URL shortener. I wanted to see a story posted by the local BBC outfit on Twitter that carried such a link. But the bbc.in link redirected to bit.ly… trouble is bit.ly is currently blocked by Sky Broadband Shield for phishing or malware. Actually there’s not surprise there given what bit.ly et al do.
Later on the redirect from bbc.in went to trib.al which is not blocked and that then took me to a BBC page.
So… given the BBC owns bbc.in why not put a URL shortener there and avoid these external, uncontrolled ones? I mean, these externals are bound to continue to cause issues.
I’ve had a couple of JT9 attempts these past two days on 20m where I’ve answered a CQ and received a signal report back, and sent mine but then received the same -nn signal report again. And again. Presumably the remote station has not been able to decode my reply. So I never get to the 73. I’m guessing the band just fades away from underneath me…
If I remember right it was the same remote station each time. I’ve had successful JT9 QSOs so I am putting these down to bad luck and I hope the other guy isn’t getting frustrated!
Well another first for me tonight, a JT9 QSO, and on my second attempts at answering a CQ. This was with a USA station apparently over a 5,600km path. But again the replies come in the Band Activity window on a different frequency. Not sure what I am doing wrong there, but this was a complete QSO ‘by the book’.
Edit: I never did follow up on this post. This is, of course perfectly normal operation, for example where someone sits on a quiet part of the segment but listens across the whole.
I spent a couple of hours yesterday with WSJT-X trying to make some contacts by answering CQs and getting nowhere. After a lot of fiddling with settings (I spotted the ALC on the FT450D was going haywire – who’d have though it had a display!) I now have much better settings of sound system output and Tx control on the SignaLink. The Tx is now set to just below to 9 o’clock position, so almost to the third tick mark, and the sound system output is set to 29% via the Pulseaudio volume control. The power setting in WSJT-X is set to -0.9db at which level the signal still triggers the PTT relay in the SignaLink but at 100% (-0db) the ALC triggers. But no luck with answering CQs.
Actually the Pulseaudio setting threw me at first because WSJT-X uses ALSA, but the ALSAmixer shows the same 29% as set by Pulseaudio so I’m not fussing. Also, it still gives the expected power output on the PS modes and a test call on BPSK31 worked fine, so it’s all be written down.
And today I got a reply to my reply to a CQ. But it was confusing. WSJT-X has two windows, one for Band Activity and one for Rx Frequency. It’s all made very easy, you double-click on a CQ in the band Activity window and it moves your Tx and Rx frequencies to that station and pre-fills standard messages. The system can also be set to enable Tx when you click but I’ve not done this. There is time (seconds) between clicking the callsign, checking everything is ok and clicking Enable Tx.
So back to my first JT65 QSO. I clicked on a CQ as above and clicked Enable Tx and off went my reply. Remember these take a full minute each, with replies coming in a few seconds ahead of the minute mark, and everyone’s clock must be very accurate or it does not work. Well, the next message from the CQ’ing station, the reply to me showing my remotely received signal strength came on a different frequency. So it displayed in the Band Activity window and not the Rx window as I had expected. But it was a valid reply and so my next one went out – my reply including R-xx, R for received and the -xx being the strength of the station as received by me. The next message from the remote station was the same as the previous, i.e. my signal strength as received. So I halted the transmission there assuming I had got something wrong.
So not a complete QSO but I received an eQSL card for it and so I am counting it as my first ever on JT65, and it proves my system works.
Anyway I persevered amongst other things and managed a complete JT65 QSO later in the day, but the replies still came back in the Band Activity window on a different frequency than my transmissions, and the original CQ that I answered still showing in the Rx Frequency window. Why the difference? The QSO ran fine, all messages exchanges right to the 73’s. When I can see both sides of other QSOs, or even the relevant bits they all appear at the same frequency. (note ‘frequency’ here is that displayed by WSJT-X in Hz, not the dial frequency)
One thing I’ve noticed is the screen required for these digital modes. I have a 22″ 16:9 screen and I had a secondary 19″ 4:3 one attached when I was writing my Ph.D. but it generated a load of RF hash. So now I just have the 22″ and it’s not big enough!
Many shack photos show dual screens or even dual PCs and multiple screens and I can see why. Ok I have the MacBook for logging and other things, but the shack PC desperately needs more screen size and/or more screens. Something else to work on. Unfortunately the PC is a scrapper that has no HDMI output so I am limited to a DVI and a VGA screen. Hmmm… so I need a better PC too…
I am just beginning to experiment with JT65 having set up WSJT-X recently and the screen is full.
So far I have totted up 19 countries – finally including the UK. I managed a BPSK63 QSO with a station just a few miles away, on 20m again as this is still my only HF antenna. I’m guessing this was ground wave. Funny, I’ve been interested in, and fiddling with radio for 40+ years and yet I am only now learning about propagation, helped in a large part to the two pieces in TX Factor. See http://www.txfilms.co.uk/txfactor/ – these are really good programmes.
Typical networked devices, including the ubiquitous smartphone have a now well known address – the IP address used to route information across the Internet. But there is another, less well known address which can be far more revealing of the actual device. This is the MAC (Media Access Control) address. Where the IP address is needed to enable end to end communication across the Internet, the MAC address deals with physically addressing devices on the local network. Unlike the IP address which is stamped on every packet of data, the MAC address does not bother with such things. It is a low level address, in Level 2 of the OSI model, or in the physical layer in IP terms. It deals with moving data – whatever that may be – between connected things. Examples include your smartTV and home router, or your smartphone and a wifi hub. Your smartphone passes data to the wifi hub using the wifi hub’s MAC address and vice versa. The wifi hub in turn passes the data onwards to, say your home router using the home router’s MAC address and vice versa. And so on.
MAC addresses are 48-bit addresses broken into two parts. The first 3 bytes (24 bits) are known as the Organisationally Unique Identifier (OUI) and companies purchase and register these with the controlling body, the Institute of Electrical and Electronics Engineers (IEEE). The second half is a unique serial number assigned to a Network Interface Card (NIC) (or most probably these days a chip, not an actual card).
MAC addresses were designed to be globally unique but the first byte contains a one bit flag to indicate if the address truly is global, or local. Local addresses are by definition not globally unique. A second type of identifier, the Company ID is formed from the same first 3 bytes but with the flag set to local.
Now, the first part of the problem is these first three bytes identify the manufacturer or company, so you can see how a MAC address can be used in a useful way by a surveilling agency. Even with such generic data, when faced with a room full of Android owners the one iPhone owner will stick out.
But there is a far more major issue. Although these MAC addresses are meaningless in wider Internet terms they are nonetheless supposed to be globally unique. And there is the issue. Were a global adversary able to inspect every thing in the Internet looking for MAC addresses then a device, a smartphone say could be traced across the planet.
To get round this issue operating systems can randomise the MAC address. This was intended as a privacy enhancing technique but unfortunately researchers have discovered multiple flaws in the various randomisation techniques used by system makers which enabled them to defeat the randomisation of MAC addresses in 96% of Android phones. They too teir work further to examine an attack method which can identify the global MAC address of a device even when it is in a randomised state.
See also http://papers.mathyvanhoef.com/asiaccs2016.pdf and https://lirias.kuleuven.be/bitstream/123456789/547642/1/wisec2016.pdf