Thanks for confirming, Marcel!
Jason, coming back to your enquiry over the SCOUT:
[quote jll74556]I've noticed that the scout appears to have some data encoded into it (some variation of the NET ID?), even though it appears to be completely ignored, however can this data be used to reliably differentiate between the standard protocol and TK2 protocol?[/quote]
This discussion really now belongs in the HW or SW section of the forum, but I'll leave it to you to continue the thread elsewhere hereafter, if you wish...
As mentioned below, the SCOUT serves two purposes - one to allow any receiving stations to detect the start of a new packet and synchronise reception with the sender and secondly for the sender to detect any collisions/contention (or a 'bad-line.')
In practice, due to the PNP arrangement in the NET hardware - either sourcing current in to the network, or switched off - only when you attempt to 'send' a low/zero (switched-off) can you detect whether someone else is concurrently also sending a high/one level (sourcing current). Thus the SCOUT is arranged to include a (arguably) unique selection of ones/zeros. The ones allow the SCOUT to be detected by the listener, the zeros to allow the sender to detect collision with a concurrent sender.
Across the various implemenations of the QL NET - and even the ZX Net as per the Spectrum + Interface-1 - various permutations of SCOUT can be seen, mostly based on the SRC station address (0-64) - either inverted or actual. In some cases, a mix of the SRC and DST station numbers is used - again, inverted or actual. The SCOUT typically starts with a minimum length of high/one level bits to ensure it can be reliably 'caught' by any listeners.
Under TK2, the SCOUT is also extended (remaining high) by a whopping 5ms for any Broadcast sends, knowing that any receivers currently expecting a Broadcast are also sampling the Keyboard between attempts to detect the SCOUT, which might take a couple of ms each round.
In practice, the SCOUT is an 8 or 15/16 bit value (depending upon OS platform), transmitted at a lower bit-rate to the real data which will follow (30 or 60 us per bit vs. 11.2 us for actual data.)
However, the only critical aspect of the SCOUT is that it must have no further high-to-low transitions after around 525 ms following the very start of the SCOUT going high. The next high-to-low transition is then taken by any receiver to be the beginning of the START bit of the very first byte of the 8-byte Packet Header.
With some care and a fast enough receiver, you could make a reasonably educated guess as to the OS platform of the sender by sampling the SCOUT. In fact, with a bit of ingenuity, you could safely use the SCOUT period to encode a few bits of more useful data (8-10) that tell any suitably programmed receiver more about yourself or your 'capabilities' in a way that is entirely transparent/invisible to existing NET devices - an idea that I've been toying with
Once you fire-up a new thread, I'll provide a more direct answer to your question as to how to differentiate a TK2 sender from a vanilla QDOS (or ZX Spectrum!)
M.