|
|
Post by ayelix on Oct 23, 2016 21:00:39 GMT
I recorded the activity on all of the test points and some of the micro pins on startup. I'll put the short version here, but all the details and scope captures are in my xylo5-c repo on github: github.com/Ayelix/xylo5-C/tree/master/startup_behaviorThe conclusions I came to are: - The LEDs flash ~165ms after powerup and the flash lasts 110ms.
- TP1 (the test point not connected to anything else) goes high ~105ms after power-up and goes low when the LED flash starts.
- Each color channel (red, green, blue) is controlled one at a time in sequential 250us time-slots.
- The color channel controls are pulsing constantly, even when the LEDs are not on.
- The TP7 control signal (for the MOSFET which switches all color cathodes on/off together) appears to be used for overall on/off control.
But there is definitely at least one thing I'm not sure about: Why is the fourth MOSFET (the one controlled by TP7) included?
Couldn't the brightness of each color channel be controlled independently, including being able to turn them all the way off? Why not just stop the pulses on each color channel to keep them off?
I have one theory, but it doesn't make very much sense. Maybe the color channel controls are used to set the RGB color assuming full brightness. Then the TP7 control is used for brightness control via PWM? That seems like it would be difficult because the PWM frequency would have to be pretty low. Assuming you wanted at least 100 brightness levels, you would have to divide the 1.333kHz frequency of the color channel controls by 100, giving you only 13.33Hz. Seems like flickering would be visible at 13.33Hz, especially with people waving the wristbands around on their wrist (since movement makes flickering more noticeable).
Any thoughts? Any other measurements I should take? I have a unit with every test point and every SKT6 signal wired up for easy measurement.
|
|
|
|
Post by ayelix on Oct 23, 2016 21:24:18 GMT
Note on the ATMega pinout: the only output compare pin connected to the LED control circuit is PD3, which may be TC0 OC2B. The color channel controls are not on timer-connected pins, so it seems they must be software-controlled?
|
|
|
|
Post by ayelix on Oct 23, 2016 22:47:38 GMT
I just realized there's another possible explanation for the 4-MOSFET setup that seems a lot more reasonable to me. If the 250us color channel pulses continue constantly (no matter the current LED color), then the TP7 control could be PWM'd within each 250us time-slot to control the brightness of the active color. That way the control only requires one output compare channel and the rest could be used for other purposes. That could explain why only TP7 is connected to an output compare channel! And also why I never saw any PWM on TP7 - that's expected if the initial pulse is at full brightness (100% duty cycle).
I'm just guessing here... ¯\_(ツ)_/¯
|
|
martincollett
New Member
Posts: 5 
Xyloband type: Speaker Model, xylo5-C Model, No Speaker, Hardwired LEDs Model
|
Post by martincollett on Oct 24, 2016 13:19:33 GMT
Hi Ayelix,
I've spent some time playing with the 5C and can confirm, it's one mosfet per LED channel. The fourth is a ground supply to the other 3 mosfets, it has to be on before any LED can be on.
Cheers,
Martin
|
|
martincollett
New Member
Posts: 5
Xyloband type: Speaker Model, xylo5-C Model, No Speaker, Hardwired LEDs Model
|
Post by martincollett on Nov 13, 2016 10:52:38 GMT
Hi Ayelix, I have an unactivated xyloband connected to a Saleae logic analyser, I've attached the capture and setup files from the band starting up here. I'm monitoring the MCU ports directly - PB6 is red, PB7 blue, PC3 green, PD3 enable. I'm not sure how / why they are generating PWM signals on those ports that don't seem to support it? Hope this is useful! Martin |
|
martincollett
New Member
Posts: 5
Xyloband type: Speaker Model, xylo5-C Model, No Speaker, Hardwired LEDs Model
|
Post by martincollett on Nov 13, 2016 11:42:45 GMT
Ayelix, I've re-read your original post in this thread and I can now understand what you are suggesting. It sounds likely, the LEDs are enabled R,G,B in sequence, the PWM enable signal is used to set the brightness for each colour in its time slot.
|
|
|
|
Post by ayelix on Nov 24, 2016 23:10:36 GMT
I have erased the micro on one of my units and written some new software to try to reproduce the LED control that I think they may have been using. I have problems syncronizing the RBG pins (which are software-driven, not directly timer-driven) with the enable pin (which is directly timer-driven - PWM). At the low clock speed that I was using (1MHz), the 10-20 cycle interrupt handling overhead is significant enough to cause visible glitches in the LED control. Effectively, the RGB sequencing is delayed relative to the enable PWM signal due to the software overhead.
I'll have to look into the clock settings more. Simply increasing the clock frequency (along with using software control on the enable pin) might be enough to get them all in sync.
|
|
martincollett
New Member
Posts: 5
Xyloband type: Speaker Model, xylo5-C Model, No Speaker, Hardwired LEDs Model
|
Post by martincollett on Nov 29, 2016 15:21:21 GMT
Hi Ayelix,
I too have programmed a xyloband to do the PWM as you first described. I did have problems with colour glitching, but solved it by manipulating TCNT2 in the interrupt handler. Setting TCNT2 = 0x00 at the start of the interrupt, then setting TCNT2 = 0xFE at the end did let me synchronise the PWM with the LED enable signals. I am using the 8MHz internal clock though which might also help.
All the best,
Martin
|
|
|
|
Post by philipp900 on Sept 1, 2017 23:04:48 GMT
Hi Ayelix and Martin,
Could you please explain what hardware and software you used to reprogram the Atmega.
How to clear the protection.
I have some programming skills and would like to mess around a bit.
Thanks a lot
|
|
martincollett
New Member
Posts: 5
Xyloband type: Speaker Model, xylo5-C Model, No Speaker, Hardwired LEDs Model
|
Post by martincollett on Sept 2, 2017 16:35:40 GMT
Hi philipp, I used an Atmel-ICE programmer, www.atmel.com/tools/atatmel-ice.aspx and the Atmel Studio IDE www.atmel.com/microsite/atmel-studio/Clearing the copy protect fuse is easy using these tools, but you have to erase the chip to do it. You can't ever see the currently programmed firmware in the chip. I'll try to draw the pinout of the two unpopulated connectors on the Xylo 5C below, numbers in brackets are the ATmega 88PA pin numbers, they are drawn as you look down on the board: --3 pin connector - serial-- TXD(31) RXD(30) GND(3) ........................................VCC(2) ........................................RESET(1) ........................................SCK(5) 6 pin connector ........................................MISO(4) ........................................MOSI(6) ........................................GND(3) The 6 pin connector is where you connect the Atmel-ICE for programming, you'll have to make up your own lead to do this. Good luck! Martin |
|
|
|
Post by philipp900 on Sept 2, 2017 20:54:26 GMT
Hi Martin,
Thanks a lot.
The pinout is already of great help.
I will order a USB programmer and give it a try.
Do you have any code samples that you are willing to share?
Best regards,
Philipp
|
|
|
|
Post by ayelix on Sept 15, 2017 21:28:31 GMT
All of my code is on this repo: github.com/Ayelix/xylo5-CNote: It does *not* work right. The control timing is off and causes RBG channels to "bleed" into each other (ex. when it's supposed to be all red, the green will come on as well). I was using a Bus Pirate as my programming interface, but that was a pain in the butt and I don't recommend it  dangerousprototypes.com/docs/Bus_Pirate_AVR_ProgrammingUsing a real AVR programmer/debugger would be way better. |
|
