Some thoughts from the field.

**mx270a** · 10-12-2008, 11:02 PM

I need to preface this by saying I'm using a fusion brain in a rather harsh environment.

As some of you have read previously, I'm using a fusion brain as the software-to-hardware link in a system that steers a machine via GPS. This spring I was plagued with bad power issues, as I was running the FB directly off the +12 rail in the vehicle. From what I can tell, there was some sort of voltage ripple that would make the PIC freak out and lock up. I had to pull power to get it to reboot. I resolved this by using an inverter to get 120VAC, then a power brick back to 12VDC.

From what I've done in testing, there are a few things I'd like to see tweaked in future releases, and you may have already addressed these in the upcoming revision:

-Something that will tolerate all kinds of nasty voltage spikes and drops coming in. Maybe just a larger capacitor on the 5V side would be enough.

-A watchdog so that if the PIC locks up, it reboots and things continue to function as if nothing ever happened.

-Something so that if data isn't received within X milliseconds, the brain shuts off all outputs. Just a fail-safe. Since I'm working with vehicle steering, the lack of this alone kills my ability to market my product for use with the Fusion Brain.

**greenman100** · 10-13-2008, 01:49 AM

Power supply:
It could be improved, and is in the version we're alpha testing now. Hopefully it'll work better, but it isn't a fully isolated switching mode, like your inverter basically is.

Watchdog:
We have the ability to do this in firmware, just have to code for it.

Auto-shutoff:
We have the ability to do this, too, and it should be in our next firmware.

**Bugbyte** · 10-13-2008, 09:13 AM

Originally Posted by mx270a

-Something that will tolerate all kinds of nasty voltage spikes and drops coming in. Maybe just a larger capacitor on the 5V side would be enough.

First, the application to steering is way cool. Second, try just using a simple 12 volt regulator like the Carnetix 2160 to smooth out the highs and lows. It may be simpler than trying to build it all in to the FB.

**mx270a** · 10-13-2008, 09:32 AM

Ok, cool.

If the PIC can reboot when it locks up (due to power issues), and be able to resume operation in just a few milliseconds, then I don't necessarily have to fix the power issue.

My knowledge of USB protocol is lacking, but is it possible to eliminate the handshake stuff during initialization? Something where the software just starts issuing commands to a VID/PID and the PIC processes them. When it quits receiving data, it would wait for the timeout and shut the outputs off. Can this be done? Seems to me that if the PIC does reboot, I would have to run through the initialization routine again.

**2k1Toaster** · 10-14-2008, 01:25 AM

Originally Posted by mx270a

Ok, cool.

If the PIC can reboot when it locks up (due to power issues), and be able to resume operation in just a few milliseconds, then I don't necessarily have to fix the power issue.

My knowledge of USB protocol is lacking, but is it possible to eliminate the handshake stuff during initialization? Something where the software just starts issuing commands to a VID/PID and the PIC processes them. When it quits receiving data, it would wait for the timeout and shut the outputs off. Can this be done? Seems to me that if the PIC does reboot, I would have to run through the initialization routine again.

The handshake stuff is pretty much part of USB. When your device connects, the OS gives it a unique name based on where it is and what else is running. It creates a virtual file handle that you basically read and write too which cooresponds with the device. If you still have that virtual file open, the OS can't overwrite it but will generate a new one.

I am seeing what I can do to automate the process of reconnecting to a different handle if one is lost. I will let you know if I find something.

**mx270a** · 10-19-2008, 09:32 PM

More back story, and new details: My steering software is multi-threaded. I put all the Fusion Brain control stuff into a different thread a long time ago so if that thread hangs (due to an IO issue), the rest of the app will still be responsive. As I recall this spring, when I was having power issues, when the FB would lock up, it would leave any outputs on that were on. Thus if it's last command was to turn the wheels, it would keep doing that. Fast forward to today - I have two outputs not connected to anything, but I turn them on/off in an oscillating way. This way, one of the two will always be on, and if they're flashing, I know data is moving. Now when it quits working, all the outputs are off. Either I'm loosing the connection to the FB and it is resetting, or the software is closing the connection. When this happens, the thread is still alive, but possibly hung. I haven't attempted to debug that code while driving a combine, so that's all I know. If the software is closing down the connection for some unknown reason, it should also terminate the thread, as it does when I tell it to disconnect. Since the thread is still running, that makes me think this is some kind of USB connection issue, or the PIC locking up and resetting?

I really need to try the inverter again, but I just haven't done it.

I can't recall what firmware version I have, but what is the expected behavior when the PIC freaks out? Do all the outputs get shut off, or do they stay at the last state?

-Lance