Micro Maestro questions/issues

[Francis Bartholomew - OIT]

We had a situation crop up here in the last couple of weeks during a demo; the Micro Maestro board started sending really spurious data to the servos (causing the dish/arm to spin around wildly, and require that I pull power from the board). Then the board kept powering on and off (indicated by gaining and losing USB connectivity to the laptop - chiming over and over again), and then one final drop and the board became totally unresponsive.

No biggie, right? Jumped on amazon, found another one of the same thing, bought two of them just in case, and meant to do a drop in replacement.

Last night, after getting the new units and installing one of them, I discovered that a recent windows update had killed off the .NET 3.5 library the Paoulu Maestro software needed. Trying to run the software gave an error, tried to correct it by connecting to Windows Updates, but failed at this step. Further digging revealed the following:

- I needed to download the full Windows 10 installation media, built into an .iso.
- the .iso needed to be mounted as a disk (drive E: in my case) so that the files in the image could be read.
- There's a DISM.exe command that I needed to run, to pull the now missing or broken library into the Windows 10 installation on the laptop.

Once this was all said and done, the Paoulu software kicked on, and I was able to reset/recalibrate the Micro Maestro board, swinging the dish up and down, round and round in glee. Saved the config to the 'maestro_settings' file, and planned to make this morning a more complete test of the tracking.

Fired up spyder, loaded the tracking software, configured the COM ports correctly, calibrated, then nothing. The software even thinks it's sending commands to COM5, where the Micro Maestro is on our system - but the servo controller doesn't even twitch. The COM port and speed settings are correct so far as I can tell - but the system's acting like there's something remaining that's hard coded with information from our original board. Of course, now that I'm sitting here typing, I'm noodling over whether or not the python software is actually sending data to the servo controller board at 9600 or not. I'ma go fire up the laptop again and find out (since this would totally cause the system to think it was working, but the board being configured with a different speed wouldn't 'hear' the commands correctly)

[David MSGC]

You are right, if the baud rate is not the same between the two devices they will not communicate. The device manager will assign a different com port for each unique serial device, ie two different micro maestros will have two different com port numbers. If you have not changed the com port number going from the old maestro to a "new" one the com port number will have to changed in the python GUI. You may have noticed a different com port number in the maestro control center, if not you would not have been able to move the servos from the control center. I would suspect a mismatched baud rate or com port number. To test you can use two ftdi cables and connect with jumper wires tx of one to the rx of the other and vise versa, set the com port in the control center or the antenna gui to one of the ftdi cables. Open a serial connection with putty to the com port of other ftdi cable and you can watch in the putty terminal what the gui is sending to the maestro, you will be removing the maestro from the system, if everything works you know it is in the maestro OR it could still be wrong port number. If is is the wrong baud rate you will see a bunch of weird characters coming across the serial port in putty.
Thanks for the info in the windows update, if it were also a driver update you may have to 'hide' the driver from windows update or it will repeat the same behavior. Pololus website has a lot of useful information and they are usually pretty quick to post information regarding updates and OS driver issues, sometimes accompanied by a tutorial.

[Francis Bartholomew - OIT]

Oh boy. The things we learn from breaking things, and then writing everything down.

1. If you're going to go to the Pololu website, looking for a firmware upgrade - be certain you're pulling down the version for your model of servo controller. The fact that the file extension wasn't auto found by the firmware loader should have been a clue (and it was - don't misunderstand me. I'm just stubborn, so I loaded the wrong firmware *ANYHOW*) This will cause you to frantically read through the website's instructions on 'how to dump garbage firmware from your controller so your team doesn't stab you'. One bad firmware flush and reload later, the servo controller is no longer a tiny little lump. Hooray.
2. Plugging the originally failed board back into the laptop actually brought it back up (I still don't trust it, because it was non-responsive during a presentation) and I loaded the calibration software again, and wouldn't you know it - there's a very subtle difference in the settings, not covered in the slides (hence my coming back to the boards to let people know what I found.)

Looking closely at the serial settings tab in the Pololu Maestro Control Center, turns out the original board was set for 'USB Dual Port', something that never crops up in the 216 page 'Ground Tracking Slides Rev 7A 7.16.2016.pdf' document we built the system from (I checked. Twice.). So, one radio button later and I fired spyder back up, unchecked the arduino box (since I'm inside working out the kinks in the servos stuff, there's no point in getting hung up on the calibration step which always makes me cry a little. ) and bam - we're moving the antenna again through the use of the antenna-tracker software and not just from the Maestro software. Whew! We've got a launch coming up here in a couple weeks, and I was sweating the fact that our tracking station couldn't track.