LX7 Firmware Upgrade

I know this comes up often, but as I work in IT for a living, this shouldn't be so complicated. I have two brand new LX7's and am trying to get them up and running. I run a mac, so I'm running Parallels with a copy of windows 7. I was able to get connected to the mitras via normal USB serial ports, but when I get to the point of upgrading the firmware, I get the fixture to reboot into bootloader mode, but no matter what I do, I cannot get the driver to load for USBVCOM. I get a yellow exclamation point on the USBVCOM (COM7) device, and the following in the device properties.

Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)

any suggestions? I've tried to manually uninstall, reinstall, select the local device drivers from the program files directory, have tried multiple versions of GCC, nothing seems to want to work. I attempted to install dpinst_x64, but that didn't work either (which I did notice it was under the Win10 directory, but whatever).

No clue what to do next. I can't really program the fixtures so far - i can connect to them no problem but the connection also seems to crash when I go into the communications tab, and only the communications tab.

Attachment 9863Attachment 9864Attachment 9865

you have a PN

regards Pit

Thanks Pit for all of the help. In the end, I was unable to get a Mitras to successfully talk to control center on a Mac via parallels. I gave up on it. I know these are supposed to be good fixtures but the software is absolutely horrendous. It crashes constantly, doesn't work well consistently. There is obviously a learning curve but the UX blows.

After I threw in the Mac towel, I just busted out an old ass thinkpad (why don't those laptops ever die?) that was running windows 7 and had the firmware upgraded pretty quickly after having gained oodles of experience working on them in Parallels. Parallels apparently doesn't play nice with control center, but no clue why. Something is weird about that particular vcom USB driver when the light is in bootloader mode.

Now I'm at the point that I'm just trying to get them to connect to myghl so I can maybe maintain them over the network instead of USB. The one that won't ping can't seem to connect to myghl consistently - it won't let me add it anyway. I can only get one of these to ping about 25% of the time, the other pings 100% of the time but I can't log into the web interface on either of them to update the wifi firmware. It asks for the htpassword then just times out or I get "the connection was reset". It's just frustrating to spend a few days just trying to get LIGHTS going.

For the life of me, I don't know how I'm supposed to update the WiFi firmware over the wifi connection, when the wifi connection doesn't work worth a hoot.

I take it back. Neither of them ping worth a crap now.Attachment 9866Attachment 9867

The issue you had with the USBVCOM driver was due to the current driver no longer supporting Windows 7. The fix to this would have been to use an older version of GCC which we could have provided you with.

As for the WiFi, make sure both fixtures are running on the newest module firmware. You can update the firmware in 2 ways, through the web browser OR with our WiFi update tool which can be found here:
https://www.aquariumcomputer.com/dow...irmware-v6512/

The WiFi update tool allows you to do the update via a USB connection instead of going through your network.

If these intermittent disconnects continue, assign a Static IP to your fixtures.

Hi Vinny
2 suggestions - modify the download page to remove Windows 7 as being compatible with the new versions of GCC and probably upload the compatible version and label it as such. Or, include the old version of the driver as a separate download, then maybe it'd work with the new GCC versions?

I was able to get things working on this old thinkpad to the point where I could actually access the communications tab. Lots of error 41's and this and that, crashes, etc. But after 3 or so hours of working on it tonight, I have them both working. I found and downloaded the update tool. One of my fixtures went fairly smoothly. The other required many reboots, usb cable pulls, etc, to get the update to apply itself. It would just try and try to reset the controller and nothing would ever work, then at one point it just went through.

Still pretty ********** with the lights. They're beautiful fixtures, and from what I hear, great performers, but damn the setup process is a HUGE PITA. Hopefully I can keep them online and get some profiles loaded onto them once I get my tank filled. Thanks for taking the time to reply. Me being way overseas doesn't help things. Had to rely on the forums and google translate to inch me along to some working fixtures.

One quick question (that's probably outlined somewhere) - if the lights are on the network, is there any benefit to forming a master/slave relationship if they're both running identical programming, or is that just for cloud movement type things?

Since you have multiple fixtures, it would be more convenient to set 1 as a Master and others as Slave units. This will allow you to make lighting schedule changes to the Master fixture, which then gets transferred over to the Slave fixtures automatically. Having both fixtures on your network also has its benefits.

You can separately connect to them and individually set their total output percentages; HE or HO and %. You will also be able to adjust the Power Balancing Tech features and select which channels you would like to send more power to.

Thanks Vinny. I can't ever imagine a situation where they'd have different programming, so I think it's best to do a master/slave configuration.

Am I correct to assume that once a light is turned into a slave, wifi is disabled and it will no longer appear on the network? All configuration and programming would be passed along by the master, then.

Does master/slave complicate firmware upgrades or make them easier? I.E. I upgrade one fixture and the other is upgraded automatically?

Turning one fixture into a slave will not disable the WiFi module. If you already have it connected to your WiFi network, it will remain connected even as a Slave for the reason I mentioned earlier. Changing a fixture to slave mode also does NOT have any effect on how you do firmware updates, it will still be carried out in the same way. Updates are done individually.