Assembled first IMP03 board with success

I used the hardware reference design to create a (Teensy-size) breakout board and finally got a chance to assemble one today. I am always pleasantly surprised when things work the first time I try something. I got the device to blink up with an iPad, but i didn’t get the hello world program to respond probably because I had to turn the iPad off to recharge it. Is the phone or iPad necessary as a wifi link in order to program and use the IMP03? Anyway, I am ready to start learning how to make use of this device and I will start with the tutorials. Any advice for how to make the learning process as fast and smooth as possible? I’ve attached a picture of the new born.

Here is what it looks like:

That is cute. No, the mobile device is used solely for BlinkUp, ie. configuration. The imp003 connects through its own WiFi sub-system and the antenna you’ve build into the board. Once you’ve configured the device, it connects to the Cloud and you can access it via the IDE.

Thanks, being new it took me a day to figure this out and go through the basic tutorials. It’s pretty cool to upload the new programming via a web browser, and control the board function by entering a device address. I also like the way the IMP shuts itself off after a few seconds of idleness. I’m thinking I really need a lower quiescent current for my voltage regulator (don’t say I told you so, Hugo!).

Er, shuts itself off after a few seconds of idleness, you say? It doesn’t do that, unless you yourself have written Squirrel code to do it. (By default, it shuts itself off after a minute if it can’t connect to wifi, though Squirrel code can change that behaviour too.) If it’s shutting down without a Squirrel call explicitly telling it to (imp.deepsleepfor, etc) then there might be a hardware problem. Does it wake up again by itself? If so, what is hardware.wakereason()?

Peter

I’m assuming @onehorse means the blinking green LED… I hope :slight_smile:

Yes, I mean when I power up the board, the green led blinks for about a minute then stops. I naively assumed the imp was going into an idle mode, but in fact the pin N (blue) led blink program I loaded yesterday also starts up when power comes on. So it seems the end of the green led blinking means something else.

By the way, the 0404 rgb led works well here. Pin N controls the blue led of the common-anode rgb led with the red and green reserved for the blink up pins. I was able to blink up on the first try with no trouble, the blue led never lights unless pin N is specifically pulled low by hardware pin write command and the led is far enough away from the photodetector not to interfere. Well, I covered it with my finger during blink up just in case!

Any idea how i can test the range of the wifi? I used a 2.7 nH inductor and 0.8 pF cap for the antenna pi network, slightly different values from the reference design, but they seem to work OK. The imp seems to work all throughout the house, I just wonder if there is a utility to gauge wifi strength/range or some such.

imp.rssi() will give you the signal strength: https://electricimp.com/docs/api/imp/rssi/

Great, thank you.

I did a poor mans signal strength test by having my some toggle the led on and off on my laptop at home while I walked away from my house, I got out to about 100 feet from the house before the led stopped blinking, either because he was distracted, got bored, or that really is the range fo this board. I’ll check the rssi function.

On another note, I started translating my teensiduino sketch for the MPU9250 into squirrel (or at least impish) and got the accel/gyro and mag to ACK. In a few more hours I’ll have Madgwick’s sensor fusion running on it. I am anxious to see what kind of fusion rates can be achieved with a 144 MHz processor with a floating point engine.

I tried it out and got -54 dbm at my desk and -68 dbm at the end of the house. i guess this is good enough. What does the typical well-tuned imp produce? In other words, how badly is my antenna tuned?

You can do a poor man’s test without requiring offspring involvement by having the agent send a toggle every second to the device - that’s still sending a command over the connection to the imp.

It’s almost impossible to compare RSSIs unless you have a reference device on the same network in the same location (and even then you can easily be +/-6dB). -54 and -68 are good strong signals though.

You’re unlikely to get great sensor fusion performance given the imp is bytecode interpreting your code, though - we currently don’t use the hardware FP either, though enabling that would likely not make much difference given the interpreter… you may get better performance sending the raw sensor readings to the agent and doing the calculations there.

On the Teensy at 72 MHz (Cortex M4 but no FPU) I am getting typically 1600 Hz for Madgwick fusion which is plenty for a 200 Hz sample rate. On the STM32F401 I can get almost 4 kHz. On the nRF51 I am getting 400 Hz but it only has a Cortex M0 running at 16 MHz. Anything at or above 1 kHz is great, but why isn’t the full capability of the processor available to the user? Is there a write up to explain this?

It’s simple; the imp runs a bytecode VM. It’s not running native code. This allows for the OS and application to have full separation even on tiny MCUs, which means we can maintain the OS beneath applications, and we can manage power, clocks, I/O and memory for those applications.

That is a nice looking board! Did you hand reflow that? I’m looking at doing some work with the IMP003 with a few other guys and am finding that the only dev board is the more expensive dev board kit. I wish there were units available like what you have made.

Yes, I put that together with low-temperature solder paste and a hot air gun. I’d be willing to sell you one…or more if you really like them!

PM me at onehorse@earthlink.net.

I managed to get accelerations, rotations, magnetic field, pressure, and temperature out from my MPU9250 + MS5637 sensor board. I learned a lot about the oddities of Squirrel versus Arduino. Next is the sensor fusion. There seems to be a lot of latency; I suppose this is what you were talking about Hugo.

I implemented the timing function from this blog post and tried a few of the tips, but everything I tried made the time a bit longer. of course, the time to begin with was just 145 microseconds so I don’t need big savings. I am happy to make use of the local designator at the top of the program; this is closer to what I am used to anyway.

My program is more like a unitary Arduino sketch than a classic C program with header file and .cpp file, classes and structs. I made is simple so I can understand it. Still, it works well and is well commented. Is there any interest in having me posting it somewhere so others can use it? I still need to get the sensor fusion part translated but this should be straightforward. I’ll post it on github as I normally do.