Comment by throwaway894345 | Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

throwaway894345

Hey, I worked on the touchscreen at the end of the armrest. Internally at John Deere it was called GSix (6th generation). Built with Qt, WindRiver Linux, ran on a custom board (that 1"+ thick display is _just_ the monitor), resistive touch screen, speaks CAN/j1939/etc. One of the things it talked to was a buggy Bosch radio over a home-grown protocol that didn't actually expose the radio's state, so the display was forced to make educated guesses. This was a huge pain, especially WRT bluetooth pairing (at one point we had an error screen that told the user to just power cycle the radio because the display has already tried everything we could think of to get the radio back into a good state).

The contractors for whom I originally took over apparently had a contract to write unit tests, probably for a certain amount of test coverage or something. There was a bunch of dead code buried that was only executed by the tests, apparently to bump up their unit test coverage. This was one of many such horrors. We ultimately told management that it was cheaper to rewrite the thing than it was to fix their backlog of "must have" bugfixes, and it was a huge success. Still didn't fix the radio issues, however.

I've done a few projects interfacing embedded devices, and the "I must guess at the device's state because the manufacturer didn't think communicating that was important" scenario fills me with sadness and rage. I'd love to slap around every developer who thought that making such a device was a good idea.

That's a problem with abstraction layers and hiding state, observability goes into the toilet.

Interesting thing I learned about designing production test equipment. If you show the operator all the nasty state information they quickly learn to associate trashy diagnostic output with corrective action. That janky message means, run it again, it'll pass. This other one means that row of pogo pins needs to be replaced.

Hopefully if you ever end up working on a device with firmware I’ve written, you’ll end up pleasantly surprised. I’ve worked all over up and down the hardware/software stack from mobile UI down to gate-level design, and one of the biggest principles I’ve picked up over the years is that observability is absolutely a hard requirement. I’ve felt your pain myself and refuse to design systems that inflict that pain on others :)

You're a gem in the embedded world of almost pure coal and dirt mixture.

I also want to stab embedded developers with a pin header if they ever try to use a touch screen. About the only place a touch screen makes sense and is provably better is your phone. Any other application of a touch screen needs to be eradicated from this planet.

How about those Microsoft tabletop things?

No, your hands are gonna get tired after about 3 mins of using surface. All these futuristic videos showing what the future entails - everyone using a touch screen or a gesture - is ergonomically aggregious and completely out of touch(no pun) with reality.

It'd be cool to touch virtual objects, no?

Only with some sort of approximately-tactile feedback. Some VR systems fall completely short of this (most dataglove type devices) while other "cruder" ones (like console controllers) actually do a better job because interfaces like buttons and triggers are analogous to many real world sensations.

Thing is, it's expected of a lot of devices with a screen to have that screen be a touch screen too. I've worked on the touch screen UI for a 3D printer, one that used to have a tiny OLED and a rotating push button. Company did some usability research on that and people couldn't figure out how to use that combination.

The touch screen UI was well researched and won an award even and I dare say one function regressed because of the touch screen, but that function (manual build plate leveling where you look at the nozzle instead of the screen) you should never need any more because the rest of the machine got better.

Modern car manufacturers: "Hey let's replace this perfectly fine working knob with a touch screen that sorta looks and feels like a knob but really isn't and that will need an outrageously expensive replacement just after the warranty ends"...

Off the top of my head, systems where a touchscreen is probably better than other input:

- Ticket machines

- Food machines

- Informational kiosks

- Border control machines

Basically whenever you have a public-facing system that's designed to be used for a short period of time, with relatively simple input.

Touchscreens are more accessible than mouse/keyboards, because many people genuinely don't use mouse and keyboards at all. Furthermore, it's a lot easier to keep a touchscreen clean than a mouse and keyboard!

On the other hand, I love pushing buttons with a throwaway stick, especially during epidemics. The ATMs here just work perfectly that way.

I totally disagree - for simple actions there is no need for a touchscreen. Just put a button and a label. And LED to confirm the action, buzzer if sound is needed. That is all you need.

The only advantage of a touchscreen is surprisingly not the ability to touch, but the ability to reconfigure the input interface through software. When you don't need to reconfigure things, encoders, toggles, push buttons, rotary switches, etc. are far superior (with some downsides - cost, reliability).

> for simple actions there is no need for a touchscreen.

Ok, here's a simple action, that's often solved by touchscreens - Choose a destination from a ticket machine. Let's start with the button-first approach. Here's what the London Underground ticket machines used to look like:

https://pbs.twimg.com/media/B96DRJQIIAE_y1n?format=jpg&name=...

Impossible to sort, filter, search, translate, display updates...

Possibly very efficient for people who have memorized the exact locations of their stations. At least, until they have to lookup a new destination.

Virtually unusable for:

* Anyone looking for a new destination (huge search time)

* First time users (huge search time)

* Non-English speakers (Instructions are in English)

And it's:

* Terrifying

* Expensive to design/build

* Expensive to maintain

* Expensive to update

Compare that to the modern interface, and I know which I'd rather use:

https://cromwell-intl.com/travel/uk/london-underground/pictu...

Genuine question - Why do you think so many systems like these touchscreens?

I had to endurance test some industrial flash EEPROM in a humidity/thermal cycling chamber to simulate failure, but the darn Atmel flash was too good. Even so, I wrote logging code that anticipated bit and block pathologies with a layer of turbo coding FEC to extend the serviceable life of the flash well beyond the manufacturer's spec.

Is that a good thing? One of the more important skills in engineering is meeting the design requirement as efficiently as possible.

What are you concerned about and what are you preaching about in vague, motivational quotes? Have you even ever done any embedded software development in a shipping industrial product? The only industrial flash available at the time (SLC) and already spec'ed in the manufacturing BOM had a warranted cycle time of 10^5 writes. It was doing upwards of 10^6 just fine, but it would've taken months to get close to 10^7. The desired goal was to make the flash live 10-20+ years while writing log data to spare space including data points such as temperature, voltage, errors, etc. for as long as possible.

My other pet peeve is in-band communication without escape codes. Oh, the radio connected you so now you're talking to the other end. Oh, the link got dropped so now you're talking to the radio itself. What could have been a simple search-for-sequence filter now becomes a best-guess filter. Gaaaah makes my blood boil even 5 years later.

Honestly after my experience in firmware and manufacturing I'm amazed anything every works

I graduated EE with ('understanding' but) bafflement that radio works. Like just plain old amplitude or frequency modulated radio. Madness.

I work with software now/currently. I'd be surprised it all works if only it wasn't so frequently clear that it doesn't! I suppose the idea of updates has been quite quickly ingrained in the consumer mind - software bugs are somehow more acceptable, seen as just 'to be fixed' rather than 'broken' or 'poorly made', 'not very robust'.

Hey, it's Goodhart's Law! "When a measure becomes a good target, it ceases to be a good measure."

https://www.sketchplanations.com/image/167369765942

See also Chapter 29 of Hamming's "The Art of Doing Science and Engineering": http://worrydream.com/refs/Hamming-TheArtOfDoingScienceAndEn...

You get what you measure.

As they say, in the mneomic that I use to remember Goodhart’s Law, you end up getting that measure “good and hard”.

If you still work at John Deere all of your customers in the UK would love it if you could improve the anti-theft systems in the Greenstar units. It's becoming an epidemic, I've personally had 2 stolen, and know of many others, if you forget to take them out of the cab for one night they're gone. We believe they are being stolen to order by perhaps an organised group here.

Please take a look at this forum: https://thefarmingforum.co.uk/index.php?threads/greenstar-un...

I’m terribly sorry to hear that. Unfortunately I don’t work there any longer. I sincerely hope they get this issue resolved; this is awful.

> There was a bunch of dead code buried that was only executed > by the tests, apparently to bump up their unit test coverage.

I've seen this trick used before; puff up the code base with just-gotta-work type filler (e.g., adding layers of abstraction and tons of parameter checking and re-checking) in order to hit some code-coverage metric. I mean, who's going to argue about a layer of abstraction, it's an automatic good thing, right? And parameter checking is what separates us from the animals!

Encountering code like this is usually a Bad Sign.

Nice. I worked on Trimble packet radios and other products that shared the firmware codebase. Autonomous steering and "TCAS for vehicles" of JD, Cat and Case equipment had working prototypes in 2000. Back then, horizontal blade angle was doable using kinematic GPS with antennas on each end of the blade.

Thanks for your personal story - I love reading stuff like this.

Was having a relay to power cycle the radio an option?

Nope, unfortunately it was not. :(

Reply on news.ycombinator.com