DiyLightAnimation
Hardware => Lynx Zeus => Topic started by: jnealand on October 15, 2014,
-
I have a Zeus v1 that has never worked. I worked on this last February and finally gave up and put it aside. Now it is time to get all my equipment checked out. I reflashed and tested all my SSCs, used my active hub, my passive hub, got the old lights all tested, tested some new lights, etc. But when I get to the Zeus I'm stumped.
ETD to active hub to Zeus
Zeus is set to universe 1
reflashed all the pics use Zeus V6 hex
I have 3 sets of nodes attached to Ports 1, 2, 16
I used the Zeus V2 utility to set each of the above ports to channel 1 with 100 nodes.
Each individual set of nodes flashes white appropriately during the configuration process.
Bring up xlights test. Select channels 1-300 and try the RGB cycle test. NO LIGHTS.
Without stopping the xlights test, I disconnect the any one set of lights from the zeus to an SSC configured for 100 nodes starting at channel one and the lights work.
So, I know the ETD is good, I know xlights is good, I know the active hub is good, I know the lights are good, I know the communications to the zeus appear to be good since I can make them flash with the Zeus utility.
Now what??????
-
Forgot to mention that I also tried testing the lights by going direct from ETD to the Zeus.
Also while I was sitting here pondering after a minute or two all 3 strings turned on in white and I can only turn them off by powering off the PS.
-
The first thing that I would look at is the crystal oscillator. That is one of the components that all the PIC's have in common. Another common point to look at is the universe jumpers. Make sure that all of the solder joints are good. Speaking of the universe jumpers, I would also take a close look at the 485. Make sure that no pins a bent and that the socket is soldered properly. You could also try swapping it out with a known working one.
-
I would double check all those solder joints in addition to tbone321's suggestions. I had bought a low power stereo microscope for inspecting boards. It has helped my find things many times over. My vision isn't the greatest but with that scope I have eagle eyes. :)
Jerome
-
I have now reheated all the pic sockets, the oscillator, the 485 socket, the universe selectors, all the light connections. I have swapped the 485. Still no light control. Sitting on the table are 4 strings of lights all connected to an SSC and to the Zeus with all set to channel 1 of universe 1. The lights on the SSC all go thru the RGB cycle test as expected. The 3 sets attached to the Zeus all come on at the 4th white cycle that I see on the SSC. The only way to turn them off is by turning off the power supply for the Zeus. I really want to use this Zeus for my pixel tree. I have a fallback of an active hub and SSCs, but I'm trying to reduce the number of SSCs that are exposed to the weather. If I power up the zeus with pixelnet disconnected the lights never come on - just checking to see if was something not pixelnet/connectivity related. I do not have a spare oscillator. Is there a way to check the oscillator using a multimeter?
-
Try reflashing the first pic to see if this gets string 1 working.
RJ
-
I've reflashed chips 1 and 16 and swapped them. I reconfigured them using with the SS Utility V2 which is the one I have marked as for the Zeus and in fact redownloaded it two days ago from the wiki. I am using Zeus V6.hex. I can config each of the 3 strings and have the lights flashing white. When I get out of program mode and start up xlights I get nothing for a minute or two and then the 3 sets of lights turn white. If you leave things set. Sometimes one or more of the strings turn red and then eventually back to white. Once in awhile I get an all off with the first 3 nodes being red, blue and white. Then they will go back to all white. I have never experienced this kind of wierdness with other controllers.
-
You can check the oscillator by measuring the voltage on the output. If it is zero or exactly the same as the input voltage, then it is dead. If you get a voltage somewhere near 50% of the input voltage, then it is probably ok. A scope is always the best way to measure a frequency but many don't have one available.
-
I've reflashed chips 1 and 16 and swapped them. I reconfigured them using with the SS Utility V2 which is the one I have marked as for the Zeus and in fact redownloaded it two days ago from the wiki. I am using Zeus V6.hex. I can config each of the 3 strings and have the lights flashing white. When I get out of program mode and start up xlights I get nothing for a minute or two and then the 3 sets of lights turn white. If you leave things set. Sometimes one or more of the strings turn red and then eventually back to white. Once in awhile I get an all off with the first 3 nodes being red, blue and white. Then they will go back to all white. I have never experienced this kind of wierdness with other controllers.
This tells me you outputting the data from your dongle and the Zeus is seeing it or the flashing would not happen. Sure you don't have a seq software configuration issue?
RJ
-
I agree that I appear to be getting communication to the Zeus. I have the Zeus configured for pixelnet universe 1 with both jumpers on 1. My active hub is configured for universe 1, My passive hub is configured for universe 2. Everything works but the Zeus. I have lots of SSCs, They all work. I'm not using anything other than xlights test with the Zeus. I have lights on 3 ports - 1, 2, and 16. I have configured those three ports with the Zeus utility with all set to start at channel 1 and 100 nodes RGB, all have a short string of nodes on them. I connect up one SSC configured to start at channel 1 for 100 nodes and have a 100 node string attached. I bring up xlights test, select channels 1 thru 100, output to lights, go to RGB cycle and select A-B-C-All. The nodes attached to the SSC all cycle thru the colors. The nodes attached to the 3 ports on the Zeus just sit there. After at least two cycle of the colors (by watching the SSC lights), the nodes attached to the Zeus all turn white at a white cycle on the SSC. But they stay white and occasionally one or all of them will turn red. Then several color cycles later they all turn white again. I have not tried running a seq against the zeus, only xlights test function. >:( >:(
-
I am still pretty sure that it is the crystal. I do have a possible experiment that you can try but RJ may need to confirm if it would work or not.
Both the Zeus and the SSC V4 both use the same PIC and it appears the same basic circuit configuration. With this in mind, I would assume that you could take a configured PIC from a SSC V4 and it should work the same way in the Zeus. I know that they use different firmware but I would suspect that much of that has to do with how they are configured since the PIC's on the Zeus need to determine which socket they are plugged into where that is not an issue with the SSC. Since they are both RGB Pixelnet controllers, the rest of the firmware should be pretty much the same. If this is true and we have pretty much determined that both the communications portion on the Zeus is functional (responding to config utility) and that the output side is also working (nodes turning all white), then the PIC removed from the SSC and plugged into the Zeus should continue to function the same way and respond to the same channel number that it did in the SSC. If it does, then that would indicate that the Zeus board is fully functional but I bet that it doesn't.
As a final test, I would take the PIC that you removed from the Zeus and put it into the SSC (assuming that the PIC was configured on the Zeus) and it should function as it was configured. If this happens, then that confirms that the communication side of the Zeus is functional and the issue is either in the clock or the output. Unless you got all 16 outputs wrong (and I doubt that), it would appear to be an issue with the clock (crystal).
-
You can check the oscillator by measuring the voltage on the output. If it is zero or exactly the same as the input voltage, then it is dead. If you get a voltage somewhere near 50% of the input voltage, then it is probably ok. A scope is always the best way to measure a frequency but many don't have one available.
Finally got rid of all the contractors working on the house and I'm back at this. I'm not sure where the input and outputs are on the oscillator but I measure 1.67 volts DC at the oscillator pins at the top of the board and 0v at the two pins at the bottom of the board. Top and bottom being referenced by the LED and printed labels being at the top.
-
Assuming it is the crystal oscillator I went looking for a part number, but there is no mouser direct link in the wiki nor is there any reference anywhere that I can find for that part number. Since these devices seem to come in various shapes I assume I need an exact replacement in order to fit on the board. Can anyone help me with this. Or if you have a spare and can give it up I will send you payment for the device and shipping in order to avoid mouser.
-
Jim, Have you gotten anywhere with this yet? I checked to see if I had a spare crystal oscillator but no luck. Don't take this the wrong way, but did you pull the program jumper off the Zeus after programming? Everything is confirmed in the right orientation?
Jerome
-
I set this problem aside until after Halloween and while I have my lights up, still working on sequences. Yes I have the jumper off and I have been thru all the chips and other components. Also reheated all the solder joints. Since I can configure each chip and get the lights to flash I have also been told that the oscillator could not be the problem or the lights would never flash. Picked up a couple of other things to try, but I may just set it aside until next year. Got to finish up the Christmas stuff and I do have an alternative to using the Zeus by keeping to SSCs and my extra passive hub.
-
for future reference, Rick has placed the mouser direct for the zues in the wiki. have you tried changing your cat 5 cable feeding your zues? can't see that being an issue since it is flashing when programmed but it's worth a shot. good luck, I hope you get it working.
-
Since I can configure each chip and get the lights to flash I have also been told that the oscillator could not be the problem or the lights would never flash.
If RJ told you this then I may be more willing to believe it but even then...... Since NONE of the outputs are working, it really needs to be something in common with all of the outputs. Since the lights flashed when being programmed, that rules out both power and the signal outputs or nothing would have happened at all. It also rules out the signal input or once again, nothing would have happened at all. The only other things that they have in common is the program jumper and the clock oscillator.
One experiment to try is to try and program the chips with the program jumper still in the run mode. If the PIC's take the program and flash the lights, then you have a short in the program link which is holding all of the PIC's in program mode. As for the clock, there could be a few issues there. I do believe that the PIC has its own clock but it is not running at the correct frequency for what we are doing. If the PIC fail safes to its internal clock when it doesn't see a signal on the external input (and most do), then it will still be able to accept the configuration signal (timing is not critical here) but will not be clocking at the correct frequency to run the code needed to control the lights (where timing is critical).
With this in mind, there could be a few issues to look at. The first is that the oscillator has failed completely. I know that you took some measurements but not at the correct pins. You can look up the data sheet on Mouser to see what pins to use and measure from ground to output. The voltage should be about 1/2 that of the input voltage. No or full input voltage between the output and ground indicates a failed unit. BTW, pin 1 (the one at the dot) is not being used so any reading using that pin should be zero.
You can also check the part number of the oscillator and make sure that it is the correct one. It is possible that an incorrect part got into the shipment of parts to the coop manager and since they all look the same and the part number is hard to see, it is possible that it would get past the coop manager as well as the shipper that sent the parts to begin with. If it is clocking at the wrong frequency, then the output code will not run properly if at all.
The final thing is that the oscillator is running out of spec. This will also allow the PIC to accept the configuration but not control the nodes and sadly, the only way to find this is with a scope. Another thing to look at is the connection point of the oscillator. On the Zeus 16, that would be the cap above the 4th PIC. Make sure that the cap is properly soldered and not defective.