Read R/C PWM like Pulsein()

http://arduino.cc/en/Reference/pulseIn

Can I do this with Imp? Should I write my own function?

Yes and yes :slight_smile:

The pins can be configured almost as interrupts - but they will not literally interrupt like Arduino does. It is delayed depending what your code is doing.

Because of this you cannot get really accurate timing. However, everything is relative so maybe the timing can be good enough if you can get your code written so that it is typically waiting for a pulse.

I made a watt meter and wrote my code this way. The chip I used gives pulses out and so I set up an interrupt to catch those. The other portions of my code only run when I see an upward transition and I try to make sure the code will be done executing before the next pulse comes in. I am not totally done testing but I think I can capture near 400Hz.

I can see how to execute a function after a transition. How do I time it? Millis() is not fine enough since an R/C servo is 1000us-2000us? Off the top of my head without looking. I have some experience with servos on Arduino.

http://devwiki.electricimp.com/doku.php?id=electricimpapi:hardware:micros

`
local count=0,servo=0,last=0;

function pin7changed() {
local bs=hardware.pin7.read();
if(bs) count=hardware.micros()
else {
servo=hardware.micros()-count;
}
}
function myloop(){
imp.wakeup(1,myloop);
server.log(servo);
}
hardware.pin7.configure(DIGITAL_IN_PULLDOWN, pin7changed);
myloop();
`

It usually works. Get values around 1500 varying by 5-10. When I move the stick it goes from 1000-1800. Haven’t calibrated the transmitter yet. I notice that my servos don’t move as far as usual. 2 question.

Why do I get so many values of 2335 or 2336 (when it should be 1500)?
This happens about 1 in 20 values/seconds.
Why does wakeup(1) go twice as fast when there is a pinchange?
(transmitter is on)

Thanks for listening! I can code around these problems, just curious.

More experiments. It sometimes works for 5 minutes without speeding up or 2336, but once it starts it keeps going wrong.

If you trim it from 1470-1500 using the transmitter, 2336 also goes up 30+.

If you set the stick at 1200, then 2336 STILL comes up, but not as often.

For the first 1-2 minutes the variation of the readings is about 1 or 2. Perfect. Then it varies by 10-20. I can see the positive edges are about 20ms apart.

I’m wondering if the imp.wakeup() call in myloop() is occasionally triggering at about the same time as pin7changed and queuing up the callback rather than executing it immediately.

If you remove myloop() and instead do a sever.log() in your else statement, do you see the same behaviour?

`
local count=0,servo=0,last=0;

function pin7changed() {
local bs=hardware.pin7.read();
if(bs) count=hardware.micros()
else {
servo=hardware.micros()-count;
server.log(server);
}
}

hardware.pin7.configure(DIGITAL_IN_PULLDOWN, pin7changed);
`

I also made a generic Pulse class if you’re interested…

Let me know if you have any questions about it…

Tried your suggestion just to make sure. The failure mode of working for a few minutes than consistently failing with 2336 does not fit your idea, but thanks anyway! I tried it. Loads of 2336’s.

enableblinkup()?
Why does it sometimes stop blinking, then start again?
I’m unto something here.

enableblinkup(1) solved my problems!
I can see why it might interrupt my pin7changed call.
But why does wakeup(1) run nearly twice as fast?
Thanks for listening.

server.log() also caused problem while debugging with a tight loop.
That’s easy to get rid of.
I’m finished!
Now I can take input from R/C receiver, and drive a servo in real time.
Changing the data along the way however I want.
Works smooth and perfect every little movement is reproduced immediately.

It looks like you’ve worked through your issues (hurray), but in case you are curious what was going on, here is what’s happening:

  1. the imp does some power management with the clock, and when it switches between power modes it drops clock cycles. You can find more information about the issue here. This is a know bug, and we’ve fixed it in Release23. We are almost done testing Release23, and are expecting it to be released sometime next week.

  2. server.log is (currently) a blocking call. If you are using it in highly time sensitive functions, you may run into issues.

Let me know if you have any other questions!

Yes, it’s working perfectly!

“Drops a few cycles”? It goes about twice as fast.

It drops a few cycles at every clock switch. There are many clock switches happening…