Most recent activity
-
I have installed the timer Crystal (ABS06-107 and two 4pF caps) on several Pico's (v1.3 and v1.4b, firmware 2v19) for better time keeping. I'm already using this in two clocks and it's working fine for those applications.
I'm currently working on a 7 segment flip clock timer, which should start counting immediately after power is applied to the system.
The issue is that i'm experiencing a delayed interruption on the interval that is used to update the display. So with an interval of 1000ms, the 2nd second output to display is not executed.
In order to debug the issue, i've run the code below and used a scope to measure the output:
setInterval(function(){ digitalPulse(A5, 1, 10); }, 50);The results (see attached images) are that after an initial bootup of 7ms, the interval starts and runs for 1,5 seconds. Then the interval/output is interrupted for ~940ms and then continues (but slower and ramps up over the next half a second or so).
This interruption does not occur on Pico's without the Crystal, so i'm assuming this has something to do with initialising/changing the clock?
Is this correct (as in intended behaviour) and/or is there something to fix this with this setup (in firmware, or code or output pin (letting LED2 blink, has the same issue, so i don't think it's pin related))? -
Hi,
It was most likely interference on the powerline, and fixed because of the decoupling caps on all LEDs.
It's not a led strip, but through hole LEDs connected in a grid-style (large Word Clock). So the issue are the LEDs themselves (beeing other types and/or the specs on the datasheet are incorrect or based on single led applications without beeing chained ;) )
True, they recreate the signal (i've read you can use one as a makeshift level shifter because of that), so that is probably also why the data changed (interference on the power line causing one or more bits to flip).
I've hooked up B3 to a DCF77 receiver and use the DCF77 library, but i don't think that uses/needs SPI(1). On
espruino_2v17sending data worked without the SPI2 setup, but withespruino_2v17.23_pico_1r3i needed to add the SPI2 setup to make it work. So i think that last change is not an improvement.Thanks again for your effords, i'm happy to have it working now. :)
-
TL;DR: It turns out to be an electrical issue after all.
Perhaps the timings for this type of LED are not optimal and makes the LED more sensitive to interference or something. But more likely the seller cheaped out on me and did not sell APA106 LEDs but P9823 or some other clones that require external components, but i can't say for sure. In the end, soldering decoupling capacitors on all LEDS (not only a couple as i tried before) fixed the issue.
Long story:
I first tried the latestespruino_2v17.23_pico_1r3.bin, but that did not fix the issue. I had to add the SPI2 setup to make it work in the first place, so that is probably not a good change (for other users) and i would suggest to revert that?So then i started measuring again, and noticed that the signal mostly stayed the same. Then i remembered i had ordered a cheap logic analyzer in the past, but misplaced it somewhere. After finding that, i've hooked that up and started logging.
When measuring this way (and decoding as WS2813, because decoding as 2812 did not work), i saw that the values in the start where always correct (except for the first data signal after powering up, but thats ok).
So i hooked up the other chanels further along the string of LEDS. Then, after a few tries i noticed that the values changed sometimes (from 141414 which is 20 to 282828), which should not happen of course. This made me beleive that the LEDs where not functioning properly and messing up the data signal (as the signal itself looked clean on the scope).
After that, i started adding (more) decoupling capacitors on the LEDs and slowly saw that the issue was going away. As the datasheet for APA106's states that no external components are needed, i was looking the wrong way..
My apologies for wasting your time!
-
The firmware was on 2.16, so i've upgraded to 2.17 (no release formpost?) but that did not matter in this case.
So i've changed the code, so the send command is done on
BRNpress (in stead of interval). Then i could single shot capture the full signal for 160 leds (at the input for the first LED) and record a sample for a 'right' and 'wrong' moment by pressing the BTN a couple of times while resetting the single shot in between.When inspecting the last few bits of the long data signal (see attached file, where i've photoshopped the two captures over each other), it was noticable that a few bits have shifted/flipped? Where exactly the first change occures, i have not checked (as it is a very long data stream). But if that matters, i could investigate/compare further/deeper (however i doubt that this means a lot because the issue starts randomly along the line after about 16 leds, mostly in blocks.
The total length of the captured signal is the same length most of the time, so it's more like there are bits shifted as apposed to delays in the full data signal.
Just to be clear, in order to compare the data signals, i set all values to 20 (
arr.fill(20)) and console.logging thearrbefore the send command, i can confirm that thearrdata is allways the same, but the leds change (are not equally lit) everty 1-5 send command.Please let me know if you would like to have more info (video, source code, scope data...).
-
Thanks for the quick response!
When using
SPI2.send4bit(arr, 0b0001, 0b0011);(i'm using pinB15as the data line) in stead ofrequire('neopixel'), i' getting the same behaviour als with neopixel (so gradually worse along the line with varying degrees for every send command).When using
SPI2.send4bit(arr, 0b0001, 0b0111);i get random leds lighting up (random color, intensity, address) so that seems to break it :( . -
Hi, i'm trying to control 160 APA106 leds (LED Clock) with the Espruino Pico and the neopixel library.
In general, controlling the leds work (as in the addressed ones are lit up) but the brightness (an a bit of color shifting) occurres intermittently and gradually worse further along the 'strip' towards the end.
I first thought about hardware issues (because gradual issues tend to be signal/noise related), so i've replaced the power supply, added a 330 ohm resistor on the data line, added a large capacitor on the power rail, tried the af_opendrain state with pull up resistor, added a cheap transistor based buffer (which was too slow) and so then ordered a SN74HCT125N buffer (instead) to increase the data signal van 3.3 to 5v. Then i added 100nF decoupling capacitors on some leds to see if that made a difference (even if the APA106 datasheet mentions no external components are needed). But none of these measures fixes the issue.
Having searched the internet, i found out that the APA106 has different timings than the more common WS2812B or others, where the neopixel library is mainly setup for.
So that got me wondered and i bought a scope (good excuse to do so, haha). I've scoped the dataline and noticed that the signal looks quite clean and (apart from the amount of data) the same in the beginning and the end of the loop. So with the signal/data beeing fine, i measured the periods of the data and noticed that the short period is about 0.42μs and the long period is 0.85μs which is in spec for the WS2812B (and to be expected probably), but the APA106 requires a long period of 1.36μs. Even with a tolerance of .15μs the 0.85μs is too short. This probably results in some bit shifting and increase of the rgb values?
A possible solution would be to change the neopixel source code and compile/flash a complete new firmware, but that is way out of my comfort zone. And this won't allow for easy firmare updates (which i'm doing since the first kickstarter).
Perhaps it is an idea to add an additional property to the require("neopixel").write() with 3 timings or just a led type (like the NeoPixelBus Arduino lib, which has fixed this issue also)? Not sure if that is possible for compiled code. Otherwise a 'custom' APA106 function would be nice.
Or is there something other i can do (apart from changing the hardware)?
Hi Gordon,
Thanks for explaining it in detail! That's a bummer (for me in this particular application), but understandable.
Perhaps a MDBT42Q could be an alternative (as i assume that one does not have to swap and should be accurate), but i have no spares laying around.
I'll then use a Pico without the Crystal and a DS3231 module as an external reference. I've tested that in the meantime and seems to be a working 'alternative'.