I found this BlinkUp tuning guide very interesting. I didn’t know the circuits had to be tuned!
Thought I would test our current production hardware out to see if had be tuned correctly:
It looks very different to the good example you showed:
Are you able to help me understand it better. Are the high peaks needed? Why would our signal not have any high peaks at all?
Thanks
And what should good look like on the imp005? as this we what we have on a product we are developing.
The example trace with higher and lower peaks is from an android blinkup, which uses white and gr[ea]y to clock data as Android devices can’t maintain regular framerates as well as iOS devices can. An iOS blinkup will look more like the one you posted - max light levels the same. Either way it seems like you should have more gain in your setup, which on anything aside from an imp005 means increasing the resistor value.
The blinkup algorithm can work with swings down to the 0.1x level (~0.3v swing), which is why you’ve not had issues, but the more margin the better - but saturation is bad for Android blinkups, hence the tuning process.
The 005 values look just plain strange, I suspect that this is because the example blinkup capture code disables blinkup and the 005 blinkup circuit takes time to get going, hence you can’t read hardware.lightlevel fast enough on that platform. Try enabling blinkup in the example code, then - when you do the blinkup you want to sample - ensuring you move the phone away before the blinkup completes so the device doesn’t see a valid packet and end up being blinked up inadvertently. You should then see a waveform much more like the ones you capture on other devices.
We do call out blinkup tuning being a required thing in the design guides, but often people see it working and skip that. This is generally not the best idea for field compatibility.
Okay so the spread should be up to 0.6V for the high peaks?
I’ll try the mod with the imp005 and see what I get.
Well we outsourced our design but this is clearly a step they missed 
Okay so here is what I changed the code to
class BlinkUpTuner {
static NUMSAMPLES = 5000; // approximiately 5 seconds; sample rate ~ 1kHz
static function captureBlinkUp(dummy = null) {
// disable actual BlinkUp so that tuning tests don't reconfigure this device
// to use BlinkUp to reconfigure the device under test, power cycle the
// device under test and BlinkUp within 1 minute
//imp.enableblinkup(false);
// pre-allocate some space in the blob, assuming ~ 1k samples / second
// blob will be grown if necessary
local _blinkupData = blob(BlinkUpTuner.NUMSAMPLES);
// alias repeatedly-called methods for speed
local u = hardware.micros.bindenv(hardware);
local l = hardware.lightlevel.bindenv(hardware);
// sample start and end times to adjust delay for ~ 1kHz sampling
local prev = null;
local now = null;
// tight loop to collect samples
prev = u();
for (local n = 0; n < BlinkUpTuner.NUMSAMPLES; n++) {
_blinkupData.writen(u(), 'i'); // timestamp
_blinkupData.writen(l(), 'w'); // lightlevel
now = u();
imp.sleep(0.001 - ((now - prev) / 1000000.0));
prev = now;
}
_blinkupData.seek(0);
return _blinkupData;
}
}
agent.on("start", function(dummy) {
agent.send("blinkupData", BlinkUpTuner.captureBlinkUp());
});
However my graph still looks like
Also you say the capacitor needs tuning, which capacitor on this schematic? C7? What sort of values should I be trying with? Looking at the above graph the top peaks probably need to go up another 0.2V
Thanks
No, you’d need to enable blinkup (ie don’t comment out imp.enableblinkup(false), change it to imp.enableblinkup(true)).
Spread should be as the guide recommends, I think about 0.6x (not 0.6v, 0.6x of full range, which at 3.3v is about 2 volts)
The cap that needs tuning is C7, yes. In this case I’d go to 1nF and retest.
Ah okay great. Sorry thought it was enabled by default. Will order those bits in and give it a whirl.
It is, but only for 60s after a cold boot
Okay this is the code
// Copyright (c) 2015 Electric Imp
// This file is licensed under the MIT License
// http://opensource.org/licenses/MIT
//
// BlinkUp Tuning Device Code
// Collects LightLevel samples and sends them to the agent to be graphed
class BlinkUpTuner {
static NUMSAMPLES = 5000; // approximiately 5 seconds; sample rate ~ 1kHz
static function captureBlinkUp(dummy = null) {
// disable actual BlinkUp so that tuning tests don't reconfigure this device
// to use BlinkUp to reconfigure the device under test, power cycle the
// device under test and BlinkUp within 1 minute
imp.enableblinkup(true);
// pre-allocate some space in the blob, assuming ~ 1k samples / second
// blob will be grown if necessary
local _blinkupData = blob(BlinkUpTuner.NUMSAMPLES);
// alias repeatedly-called methods for speed
local u = hardware.micros.bindenv(hardware);
local l = hardware.lightlevel.bindenv(hardware);
// sample start and end times to adjust delay for ~ 1kHz sampling
local prev = null;
local now = null;
// tight loop to collect samples
prev = u();
for (local n = 0; n < BlinkUpTuner.NUMSAMPLES; n++) {
_blinkupData.writen(u(), 'i'); // timestamp
_blinkupData.writen(l(), 'w'); // lightlevel
now = u();
imp.sleep(0.001 - ((now - prev) / 1000000.0));
prev = now;
}
_blinkupData.seek(0);
return _blinkupData;
}
}
agent.on("start", function(dummy) {
agent.send("blinkupData", BlinkUpTuner.captureBlinkUp());
});
But the graph is still, any other ideas?
Hmm, you’re correct, I can replicate this. I suspect this is related to blinkup power being disabled then re-enabled; will try forcing it on and seeing what happens.
