On Fri, 5 Mar 2021 02:41:29 +0000, John Rumm
wrote:

snip

The file was of course run_me(.bat) so the 'lesson' fell at the first
hurdle. ;-(

Yup, the first doc I did that broke tech pubs was a CORAL 66 coding
standard. Just trying to get them to set out code examples in a non
proportional font, and to understand that the indentation of our
"paragraphs" really did need to be *exactly* as it was shown, even
though it was not "proper typographic layout", and no, all those
semi-colons were not a mistake!

Tell me about it. I'm still trying to deal with the various .yaml
files on Home Assistant / ESP32. ;-(

snip.

Although they did whinge that we had used the wrong sized font on our
docs, until we got out a ruler and demonstrated that ours was actually
the 12pt they specified, and theirs was only 11 because their printer
was scaling incorrectly!

Hehe. Doh!

I think it's a shame and probably held back many less progressive
British companies in the world market (who may have only survived as
long as they had because if their size and how tightly they were
imbedded with MOD contracts)?

Well in this particular case, but they had several things in their
favour. Firstly their hardware (i.e. the radio kit) was very good kit
that was widely deployed and trusted.

I remember the GEC / Marconi PCB's being quite nice (along with STC)
on the BT PCM / TDM kit I was bench repairing for BT in those days. It
was made for BT by several manufacturers, the worst being Plessy
because they used SRBP PCBs and with any modules that carried anything
heavy (Txfmrs / filters), the PCBs would often end up broken /
cracked. Remove the component(s), cut a Paxoline 'patch' to strengthen
the broken area, mark the outline on the PCB, abrade the area and the
back of patch., apply two part epoxy and glue patch on board. Later,
re drill component holes and re-fit / solder the components and repair
any broken tracks with BTC. Too many Plessy boards in your batch would
slow the batch but I was told by the union to 'slow down' as all this
stuff had agreed times and I was mucking it up. ;-(

So, given I couldn't work 'slower' I sneaked in several private
projects. I still have one here, a 'heating' indicator LED on my (BT,
fell into my bag when I left) Weller soldering station that was a
small rectified PSU (off the 24V AC transformer) that drove a led on
when the output voltage was depressed. It did a few things, it told
you when it was 'ready' from turn on (not really an issue at work as
it was on all day), it gave you an idea if it was still coping when
heating heavier joints and if the Curie tip / switch was still
working.

Secondly the competition in many
cases made the less progressive British lot look positively advanced[1],
and lastly they did (kind of) have a working example of the complete
system that the customer wanted to buy.

Yeah, I think once they had some gear working it was generally 'good'.
Visions of some very knowledgeable / Old Skool design Engineers in
there somewhere.

[1] A certain Italian maker of HF radios springs to mind. They had an
interface spec to write their radio management software against. It was
not complicated - a command response protocol using ARINC 429 serial
bus. Two 32 command words, and two 32 bit responses. The protocol
sequence is: we send command word 1, you reply with status word 1, we
send command word 2, you reply with status word 2. Here is the bit
format of all the words, and here is your ARINC bus address. Does that
sound difficult?

Nope, a pretty straightforward Enc / Ack protocol?

So there implementation: On power up, listen to the bus until you hear a
command word, assume that is for you and adopt the destination address
on it, and assume that is yours from now on. Wait for command word 1 and
do nothing. Wait for command word 2 and reply with status words 1 and 2
in sequence.

Sounds a bit like a broken CSMA/CD? ;-)

So the result was, after powered up it would grab the address for some
other peripheral, misinterpret the contents of a message not intended
for it, and then trample over the actual target devices responses, while
ignoring any we wanted it to receive!

Gawd.

We did highlight that this did not match the spec, and that they had a
fixed price contract to deliver to that spec. Could they please fix the
software ASAP? Apparently, no can do.

I was there a few times with Modem manufacturers and their
interpretations of the CCITT 'Red books' (I think it was at the time)
'recommendations'. ;-(

It's the middle of summer and the
whole factory shuts down for a 6 weeks.

Yeah, that was something a mate had to come to terms with when he
moved out there from AWE Aldermaston.

Then after that they
traditionally go on strike for another month or so while the weather is
still good!

Yup. When he came back for a visit and was a passenger with me in the
car ... and I stopped at some amber lights he looked frightened.
Apparently, in Italy (esp the South?) you *never* stopped on the amber
and so he was bracing for someone to hit us in the rear!

(in the end we had to "accommodate" it at the controller end - by making
sure that the first message sent on that bus was a HF radio one, so it
got the right address, and use a different protocol from all the other
devices!)

That sounds like running MQTT over a Zigbee HA link as it's supposed
to provide a stronger level of ETE comms but I really haven't worked
out yet how / when / why it comes in? ;-(

Cheers, T i m