RaspberryPi + LinkMeter blue sky discussion


 
Yeah I got my second Pi on Friday so it looks like Element14's delay is only about 2 weeks to the front door now. About the same amount of time it takes to get a WRT54GL delivered from an eBay auction.

I'm on the second iteration of the HeaterMeter v4.0 board which went to the fab July 25th. It usually takes 8-10 days, plus two days shipping for me to get them back. Then a day to assemble and test, plus I've got 3 days of vacation around there... suffice it to say that the boards will probably be ready before the software is.
 
Also, I assume if you had room you would have already, but it would be nice to pad/pin out as many arduino and rPi GPIO pins as possible for future expansions and board re-allocation. What you have created is more than just a grille controller, it is a really dang good start to an Arduino companion board for the rPi, which I imagine exists elsewhere, but if I must order a batch of 3 or more anyway, then hurray reuse! Add network control/monitoring to everything in the house!

I already plan to re-purpose my Heatermeter for use with a Sous-Vide setup when not in use on the grille :) A Solid state relay output (3v3 or 5v) would be great to have for controlling electric heating elements.

Thanks.
 
Now that I think about it, the fan output set at 100% "low speed" mode (instead of 10% default) should switch it over to a much slower PWM (As we call SRTP, split range time proportional) capable of driving a solid state relay that runs 60Hz 120VAC. If you switch the SSR too fast, the 60Hz signal becomes a problem, since you can only switch at a 0 crossing point of the AC Signal. You can do the equivalent of proportional control, but only if you sync to the 60Hz signal, which would require additional electronics, and is great for dimming lights, but pointless for controlling a slow system like an electric heating element.

Bryan, I have a box of nice 4-35vdc input SSRs that are good for 10A if you want me to send a few your way for testing, that is, if you have any interest in a sous vide mode on heatermeter.

Really a 'mode' would not be needed, just a profile, assuming the 'low speed' mode of fan operation is a member that is modified by the profile settings. That setting and PID gains is all that should be required to tune in a hot water bath.
 
Last edited:
Evan,
I already use my LM/HM with an SSR without issue. I use it for cold smoking ~100 degrees. Works awesome. Not sure what would need to be changed to get it to work for your application.

dave

Evan MJ said:
Now that I think about it, the fan output set at 100% "low speed" mode (instead of 10% default) should switch it over to a much slower PWM (As we call SRTP, split range time proportional) capable of driving a solid state relay that runs 60Hz 120VAC. If you switch the SSR too fast, the 60Hz signal becomes a problem, since you can only switch at a 0 crossing point of the AC Signal. You can do the equivalent of proportional control, but only if you sync to the 60Hz signal, which would require additional electronics, and is great for dimming lights, but pointless for controlling a slow system like an electric heating element.

Bryan, I have a box of nice 4-35vdc input SSRs that are good for 10A if you want me to send a few your way for testing, that is, if you have any interest in a sous vide mode on heatermeter.

Really a 'mode' would not be needed, just a profile, assuming the 'low speed' mode of fan operation is a member that is modified by the profile settings. That setting and PID gains is all that should be required to tune in a hot water bath.
Click to expand...
 
How did you hook up the SSR input? If you use the fan output, a PWM with a fast frequency will cause the SSR to switch very rapidly... it won't hurt the SSR, but the fast frequency of the PWM will turn into a "flicker" if you hook up a light bulb instead of your electric heater. Great for Halloween effects, but not so good for powering heaters. Not saying it won't work, but you'll get much better control if you turn the PWM freq down to like 1/10 Hz or so so the relay is only switching on for 5 seconds every 10 seconds (at 50% duty cycle that is). If you run 10KHz PWM @ 50% into it, you'll get "partial" power, but you will not get 50% of the power the heater can provide, since the sine wave only crosses 0v once every 60Hz. 0 crossing turn on/off is a function of SCR's used in my SSRs, maybe there are other types? The PID will balance it out, but not with very nice control since your control variable (the heater power) has a non linear and somewhat randomized response to changes in the duty cycle.

Maybe I am missing something? Maybe your heater runs at less than 10% duty cycle which changes the PWM Frequency in the default heatermeter code?
 
Last edited:
I agree in principle to what you are saying, all I know is that it works with incredible accuracy. Better than a fan/charcoal setup.

dave

Evan MJ said:
How did you hook up the SSR input? If you use the fan output, a PWM with a fast frequency will cause the SSR to switch very rapidly... it won't hurt the SSR, but the fast frequency of the PWM will turn into a "flicker" if you hook up a light bulb instead of your electric heater. Great for Halloween effects, but not so good for powering heaters. Not saying it won't work, but you'll get much better control if you turn the PWM freq down to like 1/10 Hz or so so the relay is only switching on for 5 seconds every 10 seconds (at 50% duty cycle that is). If you run 10KHz PWM @ 50% into it, you'll get "partial" power, but you will not get 50% of the power the heater can provide, since the sine wave only crosses 0v once every 60Hz. 0 crossing turn on/off is a function of SCR's used in my SSRs, maybe there are other types? The PID will balance it out, but not with very nice control since your control variable (the heater power) has a non linear and somewhat randomized response to changes in the duty cycle.

Maybe I am missing something? Maybe your heater runs at less than 10% duty cycle which changes the PWM Frequency in the default heatermeter code?
Click to expand...
 
We may be out of the woods on both my issues. I tell OpenWrt to build its crashy cfg80211.ko as a module package but to build the kernel with its cfg80211, then I bundle the kernel one with the 8192cu module. So long compat-wireless!

The other more distressing problem about the serial port spitting out wonky data appears to be a power issue. Of all the 5V power adapters in the house labeled 1A up to 2A, they all put out 4.4V-4.6V at load. With the switching power supply that I've spec'ed for HeaterMeter, I'm getting more like 4.91V at full load and haven't seen the overrun error at all in the past couple of hours. I'm going to leave it running overnight while running a monitor process and a benchmark in a loop and see if I get any errors. Hooray for quality parts?

EDIT: And Evan I actually do want a puddle machine at some point. If you do a nice post about it once you're done, I'd appreciate that!

Oh also I've shrunk the image down to 32MB overall, 6.5MB compressed, with 12MB free at first run. It includes the tools to grow the filesystem to the size of your SD card if you're so inclined
 
Last edited:
Ah feck input overruns after 2900 seconds of runtime. Ok so maybe it isn't a power issue. Also the compat-wireless fix doesn't work without some hackery so I've still got some work to do on that. Disappointing evening all around!
 
I'll do a write up if I make a "puddle" system, it should be cheap to build.

As for the serial issue, are you still coupled up with ribbon cables? Running TX and RX in parallel over long distance is not the best idea... probably not causing your issue, but if you keep them twisted and/or short, it should help.

What baud rate are you running? Any room to slow it down? You don't need a lot of bandwidth. My car's ECU spits out a lot of data at 160 baud, and it still updates it all at 10Hz or something like that.

Looking at the previous posts, it seems the problem only exists when the wifi card is loaded/powered? You might consider hooking it in via a long USB extension cable to make sure the close quarters are not causing EMI issues. If getting it away from the system does not help, and you can correlate it to the wifi card/driver, then it probably is a power or noise issue. Does the v4 board have solid and plentiful ground to the rPi? One last suggestion, maybe try powering off the p8 connector on your computer, or use a computer power supply to supply your 5v, so you can see if dirty power is an issue. I am blessed with a really nice variable power supply.
 
Last edited:
Now the boards are connected directly together so there's only an inch or two of PCB traces between the them. I don't think it is an actual communication issue, more likely there's something else that's screwing up kernel-wise. The Pi's kernel seems to still be under experimental development so there's a good chance that's the case. The fact that it works great, then will go into a period where it will screw up consistently for anywhere from seconds to hours then go back to working seems like it has to be a software problem. It even does it without the Wifi adapter plugged in so that's a good sign. I'm going to add a bunch of kernel debugging and see if I can figure out why it is overrun.

I really do want one of those bench power supplies but I'm out of space on my desk. Also even a crappy one will run me $100.
 
Sounds like you just need a shelf :P

So, the rPi does not use a generic ARM Kernel? I know it has a lot of customization... maybe consider running another distro on it like Raspian or Arch and run your serial tests... if you can get it to work, then you know for sure it is a software issue.

I wish I had more time to work on my rPi, but I would not me much help anyway, my ARM Linux skills are lacking... as are my linux programming/debugging skills in general come to think of it. I have faith.

Don't forget to take some time to make some bbq :)
 
I have a shelf! It has an oscilloscope, a couple multimeters, and some misc tools. It is admittedly a fairly small shelf.

Yeah the rPi uses a "Broadcom 2708" target, which isn't in the mainline kernel yet so they maintain their own repository. Because OpenWrt seems to really really want to build its own kernel, any rPi additions have to be included as patch files against the mainline kernel which I manually have to create from rPi's repository if I actually did it more than once. Finally, rPi uses the 3.1 kernel and OpenWrt is on the 3.3 kernel so not everything matches up. It is a whole lot of hassle until things start getting accepted upstream. OpenWrt last week sort of synced to about 4 months ago on the rPi kernel, which means bcm2708 is now in OpenWrt but I'm actually ahead of that checkpoint so it doesn't do much good.

I've also tried it under Raspbian and it fails as well. The Raspbian I have is a couple weeks old though and it is a lot of work to keep it in sync in the blind hopes that they do something that fixes it.
 
I guess watch the change log and see if others have the same problem coming up. Any chance of communicating i2c or spi instead of serial, or is that a HUGE change?
 
Evan MJ said:
Any chance of communicating i2c or spi instead of serial, or is that a HUGE change?
Click to expand...
It's pretty big. As far as I know there's no SPI Slave support in Linux which would mean HeaterMeter would have to become the SPI Slave which would mean it can't talk to the LCD or RFM12. I think I2C would be the same issue, and would require incompatible PCBs. Plus, maintaining two methods of communication in the code would be tough considering one is "write now" and the other is "wait to be read from". The serial should work though so there'd be no point in trying to implement something new (which might also have a similar problem).
 
Bryan,

I have been reading a bit, I am thinking that the onboard serial port is getting stomped on by other interrupts.

I know little to nothing about interrupts, past messing with them back in win95/NT back in the day.... but maybe I'll spur some moment of inspiration.

My Theory:

The rPi USB chip is known to have a poor driver situation... 8k interrupts per second at idle! So, something time critical like your 115kbaud serial cannot get the timing precision it needs using software interrupts, with the USB controller hogging all the interrupts. I think increased wifi and other USB traffic will cause problems with other interrupt driven 'realtime' systems.

Here is some info: http://www.element14.com/community/thread/18568?start=0&tstart=0
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7866

I think a good test would be to disable the USB driver and running a benchmark at high speed...

echo 1 > /sys/devices/platform/bcm2708_usb/bussuspend

EDIT: This may have been fixed by a patch on 7/7/12: 'echo on | sudo tee /proc/dwc_sof/SOF_reduction' to reduce interrupts... I may be way off base in that case.

Another option is to slow down the serial rate and see if you can avoid the problem... If you only send 25 bytes or some small amount at a rate of 0.5Hz, then why not slow down to 9600 baud? That gives the cpu/software serial driver 10x the time to get an idea of what the bit stream is doing, and you still get the data in a timely manner.

If either or both of those provide any positive results, we are at the mercy of the rPi kernel guys to write a better driver for the USB port that does not poll at ~8KHz. Its that, or change the priority of the interrupt used by the ttyAMA device to something higher than the USB controller. I'm not sure how to do this on linux, but I'll investigate if time permits.

If you can provide a non-hardware "loopback" benchmark for the rPi and your OpenWRT image, I can try to help if needed. I'll try to get up to speed on my own, but I imagine you'll beat me to the correct answer.
 
Last edited:
Just a few more tidbits:

Via the BCM2835 SoC datasheet:
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

I'm not sure how to dig into the cpu registers (EDIT: They get mapped to reserved RAM space), but there is a lot of useful information that could be correlated to the timing of the error log. I imagine the receive FIFO is getting full because the software cannot remove it in time for new data to arrive:

AUX_MU_STAT_REG Register (0x7E21 5064):

Receive FIFO fill level -
These bits shows how many symbols are stored in the
receive FIFO
The value is in the range 0-8

Receiver overrun -
This bit is set if there was a receiver overrun. That is:
one or more characters arrived whilst the receive
FIFO was full. The newly arrived characters have
been discarded. This bit is cleared each time the
AUX_MU_LSR_REG register is read.
 
Last edited:
Interesting information! I had seen something about 8k polling in all the reading I had done but didn't realize it was the standard USB driver throwing 8000 interrupts a second. That is just ridiculous!

I had been resistant to changing the baud rate because I thought I had some reasons:
-- 115200 baud is the default OpenWrt baud so nothing needs to terrmios() to be at the right baud
-- Optiboot runs at 115200 baud and it is difficult to time the /reset to boot to the bootloader at (HeaterMeter baud), flush and switch to 115200 for the bootloader baud
-- There is no way to tell when you overflow the serial output buffer in Arduino
-- Backward compatibility! The same code needs to run on both LinkMeter and HeaterMeterPi

But after driving homw and thinking about it:
-- I now have stty available in OpenWrt so I can change bauds in the daemon
-- I have written hmdude, which switches baudrates automatically between bootloader and heatermeter so the timing isn't an issue any more (and isn't an issue at all for Pi)
-- Arduino 1.0 now... does something... when the serial port buffer is full. I don't know if it blocks or returns 0. Golly I hope it blocks but knowing how pants-on-head retarded the Arduino people are, I bet it just drops the byte.
-- I don't see why both can't be at a lower baudrate

That said, a lower bitrate may just decrease the occurrence of the error instead of give the poor Pi enough breathing room to handle all the lovely bits I am throwing at it. I've started a test at a lower baud to see if I get any errors overnight with wifi downloading a file every minute and a benchmark running in the background.

Thanks for making me rethink my reasoning. I'm not really pleased with the solution to get around other poorly written drivers, but if it works then I guess it will be good enough for BBQ work.
 
If lowering the baud rate or sending in 8 byte bursts does indeed fix the problem, it will be a sad workaround, but at least our pits will be smoking. 9600 baud is really fast in meat smoking time at least. In the future, the baud rate can be increased when proper drivers are realized... we have to remember that though the rPi seems like a godsend for the pricepoint, it is still just a cell phone media processor with some useful peripherals. I get the idea that many are starting to realize that the limitations of the system are closer to reality than originally imagined. For the price point that is.

I'd be weary of SPI for the same reasons... though I guess results are promising so far.
 
I think you're spot on with that assessment that people are starting to see that the Pi isn't the full-fledged computer they assumed it was. It still isn't a bad deal for the price, and hopefully they'll continue to improve the drivers to make the peripherals and busses more stable over time. I wonder if they can get

I ran at 19200 baud all night with 0 overruns though, running nbench in a loop and transferring 4GB/hr through the wifi. I'm running some more tests now to see what the upper limit is. At 57600 I had 1 overrun inside of 2 hours. Trying now with 38400 just for fun but it does appear that lower baud rate is the solution for now despite me wanting to tear apart the drivers and find a better fix. I just don't have time for that!

EDIT: But the SPI bus seems to work fine. Probably because we're the master, so any hiccups just mean the transfer takes a tiny bit longer. I've been using the hmdude SPI mode to flash all sorts of programs to the AVR, which is pretty fun and something you can't easily do on a LinkMeter.
 
Last edited:
If you are the first to program avr over spi on an rPi, it might be worth spinning that into a sub-project and posting about it on the rPi forums. Seems like excellent functionality. or at least avrdude support that is. Do others already do this over SPI? I've noticed most people are not using the built in ttl level serial to talk with arduino, but instead use FTDI cables, I guess out of habit.

Doing the math, you need 200 bits in 2 seconds, which is 100 bits per second, or 100 baud (not counting overhead, etc.). So, 19200 is a factor of 100 faster than you need. Not saying it needs to go slower than 19200, but there is plenty of headroom still. I'm surprised you are only collecting data at 0.5Hz, why not go to 1s or even 10Hz? SD Cards are big these days.

6 hours = 21,600 sec
(21,600 seconds/2 second rate) * 25 bytes = 262.5KByte

Call it about 50KByte per Hour at a 2 second rate, correct?

I was curious, how do you handle the rPi's lack of a real time clock?
 
Last edited:
You must log in or register to reply here.

 

Back
Top