Space Probe, Dead Again

Ry here, update on the probe and what I’m gonna do if no-one stops me.
As of last Monday (Possibly earlier, people were in on the weekend however I don’t know if they tried to use the probe) the space probe was non-functional. Last seen working the Friday before.
The probe appeared outright dead, not responding to power, no red LED, nothing. I left it as is.

On Tuesday, when investigating further, I noticed the power adaptor was slightly loose. I removed it, then plugged it in. It was warm to the touch, more so than I would usually expect, for a device of it’s class, especially given it wasn’t doing anything. Upon plugging it back in, the power meter immediately read around 8 volts, however the device was unresponsive, and still no LED. The router didn’t report seeing it, either. I unplugged the device completely at this point.

Tonight (Wednesday), I investigated further.
From the sources still online, I’ve found a schematic of the device, and the source files.

There are a number of possible faults and solutions, I will be able to answer better once I’ve read through the source files completely, but for now, here they are:

No internet
It is possible that this is all because we’ve ran out of credit for the internet (which we have), and that the probe just does this when it’s not happy.
However, I thought at very least the red LED (or something) would light if there is power (the source files should tell me this), and the modem doesn’t report an ethernet connection.

Bad modem?
Perhaps the server on the modem’s gone down, or some general error. If so, perhaps a reboot will help?
I’ll try later, but it still doesn’t explain the probe displaying 8V on the dial and being non-responsive. Again, reading the probe’s source code should tell me something more.

Bad probe.
Perhaps the transistor driving the dial has failed, it has spent quite some time switching rather rapidly after all. If so, this needs replacement.
If my testing doesn’t reveal anything further, and I conclude a hardware failure has occurred in the probe (which I suspect is has), then my current course of action will be to remove the current internal protoboard (pictured below), along with all attached internal peripherals, as one complete unit, only desoldering the cables attached to the housing of the probe, labelling each wire showing what it was connected to, as to preserve the probe in it’s current state. This probe’s a piece of MHV history, and its nervous system is part of that history. It’s not for me to “Fix” or “Rebuild”, but right now it’s something of a mess of exposed contacts and long since removed features. With the prove as temperamental as it is, it’s time to remove one point of failure.

The board, as it is now, still installed:

Then, with the current nervous system carefully extracted, using the original EtherTen “Arduino”, I plan to re-create the current system as is, simply using new components, in a much neater fashion. Same schematics, same layout. Just cleaner.

This is provided I do not find something else at fault, anyway, typing this now I realise that because the system is all on a protoboard that I can simply buy a new protoboard, build the duplicate system on that, test it to see if it works, and if so then swap them over. No need to disconnect the probe’s current nervous system at all.

If someone who’s previously worked on the probe wants to take over at this point, be my guest (I’m putting this all on the record for a reason), but if I don’t hear any objections I’ll continue down the current path. At very least I’ll try and get the EtherTen talking with the modem again.

I’ll update here once I know definitively what’s causing the current issues, and what the possible options are.

2 Likes

Hey Ry,

The current code on the device was rewritten to use MQTT and a few other changes too.
@devdsp was the last person I know to upload config to it. If the repo on mhv’s github doesn’t have the latest changes, devdsp’s might. Otherwise can we pull it off the board? I can always ask if it’s still on devdsp’s laptop too.

1 Like

Hi Jamie,
Pulling stuff off an arduino’s a bit of a pain, we can dump the binary but not extract the code. That would only be useful for identical hardware, though, or as a emergency backup if the code is gone for good.

I’m not planning on replacing the Arduino itself, it’s the one component that I half-trust, I just plan on attaching a new board (Hat? Shield?) and hoping for the best.
I’m going in to the space tonight, and I’ll do a couple non-destructive tests on it to see for sure what’s happened. There’s a couple other things I’ve thought of that could be causing the fault, but I’ll hold my mouth until I know for sure.

1 Like

Looks like the Arduino itself is fine, it boots, it blinks, and it looks like the dial even works, half the time.
(I can’t be completely sure without the data, but I think there’s just some loose internal connections that keep disconnecting or shorting that’s giving us trouble.)

Could be the MQTT server side that’s dropping out?

Doesn’t explain why it’s so intermittent in it’s behaviour.
I’m guessing there’s a short somewhere. Also explains why the knob wasn’t working some time back.
I’m guessing the MQTT server still runs on our little TP-Link router, right? The code was never updated to talk to the twitter API natively?
Oh well, doesn’t matter. If it works fine once we’ve got data, problem solved. I still have the bits needed to tidy up the internals, but perhaps that can wait 'till the next time it dies.

MQTT runs on the server in the space that also runs the vpn etc. hostname is heimdall