RaspberryPi + LinkMeter blue sky discussion


 
Joe,

I believe the chip you linked was 3.3v only, so you would need an LDO regulator on there somewhere. Also, it is SMD only, which may not be a problem, but it is worth noting.

I think the rPi could run the PID without a problem, but you are at the mercy of a few layers of software abstraction between your code (i.e. python, c++, etc), that might be less stable than running the PID on standalone real time hardware. If the PID was much faster, the rPi would not handle it very well on its own.

I think a standalone rPi based controller sounds nice, but as Bryan mentioned many posts earlier, the required i2c/spi ADC costs just about as much as an AVR328P, so why not just include it? This way, if your SD Card gives up on you or you bork your linux distro somehow, you still have a PID controller like the other guys.

In other news, I have 90% of my HM/LM setup built for testing, the other parts ship today. I'm very excited to get it going. My scope has failed me, so I'll have to get creative with the RPM monitoring of the fan and such, but that should happen soon.
 
Sorry, I did not explain things very well. This C8051F350 part has an embedded 8051 processor, so it can run the PID loop and do everything the AVR can. On the downside, it will require different development tools than Arduino, but there are free 8051 compilers available (SDCC, Keil C51 eval version, etc.). And yes, it's a surface-mount part only, so assembly will be more difficult. One cool aspect however is that there is an experimental linux driver for programming the 8051 firmware (called C2Port) which I could adapt to work with the RPi. More details to come in a separate thread.

In parallel with this effort, I'm going to build myself a Link/HeaterMeter, just because it seems pretty awesome.
 
Good news!

I finally got my rPi to boot the OpenWRT Image... new SD Card saved the day (see page 16). I'm out of time to mess with it now, but everything looked good, I saw the interface, poked around a bit, etc. It found the wifi card, but I was not able to get it to play nice in Luci yet... I'll figure it out.

Mouser order should be in shortly so I can finish up and get some pics and data online.
 
The wifi doesn't work quite right with luci just yet. It can't do the initial scan to get configured the first time. I'm working on that, but there are a number of problems to overcome. Hopefully that will get sorted out this week.

If you feel like playing with it, you can still scan with:
ifconfig wlan0 up
iw dev wlan0 scan
 
Bryan Mayland said:
The wifi doesn't work quite right with luci just yet. It can't do the initial scan to get configured the first time. I'm working on that, but there are a number of problems to overcome. Hopefully that will get sorted out this week.

If you feel like playing with it, you can still scan with:
ifconfig wlan0 up
iw dev wlan0 scan
Click to expand...

worse case is we use a powerline and wire directly into the Rpi? Can usually find them onsale at decent prices. Wifi better but at least there is always a fall back option
 
Oh yeah the ethernet works fine, and the wifi works fine. The only thing that doesn't work is wifi scanning without the wpa_supplicant running. I can make that work by modifying the libiwinfo source to do it, but I am trying to get it working in the 8192cu driver instead of in the client app.
 
Dennis C said:
worse case is we use a powerline and wire directly into the Rpi? Can usually find them onsale at decent prices. Wifi better but at least there is always a fall back option
Click to expand...

I have a power line ethernet setup at the house, but they are kinda pricey at $40-50 per node. I was actually using it last night for comm to the rPi, so I'm not in a bind, but the $12 wifi is a much nicer option... less wires in the cook area also.
 
The fewer wires was the main selling point for building my own controller over buying a stoker. Bring out the unit and all its wires and ALSO bring out an external ethernet connection/external powered wireless adapter/router? That's too many wires!

Golly there's so much I want to do on this project still. I just imagined a wireless pit probe with a standard transreflective LCD readout on it...
 
I'm interested to see if you can just take the vertical one and bend the pins to have them fit for a horizontal installation. From the datasheet, they look like they're not molded to right angles so it should work.

I spent 4 hours last night pulling patches from the rPi git and modifying them to apply cleanly to kernel 3.3. Aaaannnnd... the questionable SD cards still error out. I then updated the loader.bin, start.elf, and bootcode.bin to the latest version to no avail. Finally, as a test, I replaced my kernel with the stock rPi 3.1 version (even though the modules won't load it should still boot right?) and that wouldn't mount the root filesystem at all. Back to the drawing board!
 
What a pain :(

I was upset to find out that none of my SD cards worked. I'm glad I asked though and bought that G-Skill one. It might be worth adding it to the wiki for people starting out to go ahead and get one ordered up. I'm sure your time is worth more than the $5 SD card. I think there are still issues with SD and rPi, maybe it will get sorted some day, but at least we identified a card that works.

As for mounting the vertical one... the pins look to be headers mounted on there somehow, I'm not terribly optimistic on bending them over, but I bet if I put some male pin headers in the hole and cut them down, I can make a right angle junction and solder it up. I'll post pics when I get it done so others don't have to mess with the long lead time part if they don't want to.
 
Yeah my time is worth more than a $5 SD card, but given that such a large percentage of our cards don't work it is something that will definitely need to be addressed. I'd dismiss it if the same card didn't work if flashed with raspbian but it does so that gives me hope that I can fix it. I also just thought about it and realized that I was pretty fatigued last night when I got to the point that I was building the image. SSHed back into my home machine and discovered I had put the combined patch in the wrong directory before building! I've got a complete rebuild going now and I can't wait to get home tonight to try it out which won't be until about 11pm. **** social life!

I don't know why the horizontal part is so rare. Digikey doesn't stock it at all and Mouser doesn't buy enough of them. When I bought the two I have, they had like 2,000 in stock so I thought it was something they sold a lot of. They're freakin' awesome compared to the 5V regulators in wall wart power supplies which dip like mad when connected to the Pi. My second Pi device which is just plugged into a powered USB hub with a "5V 3A" power supply, you can see the LCD noticeably dim as the Pi boots and then get even dimmer when the wifi module is initialized.
 
I can't say. All my Transcend cards are the class 10 variety and don't work. That may change later tonight when I flash this new image.
 
Kyle, the gskill one from a few posts back works fine. My transcend 8gb class 10 did not work on the 'current' image. Both my other cards did work with raspian though as bryan mentioned, so there is hope still. Since 4gb is overkill, I just got the 4gb card so I could start playing around. Hopefully others will be fixed by bryan soon, but as I'm not skilled enough to fix it myself, and I did not know where the priority was, I grabbed the gskill.
 
Evan MJ said:
Hopefully others will be fixed by bryan soon, but as I'm not skilled enough to fix it myself, and I did not know where the priority was, I grabbed the gskill.
Click to expand...
I tried the new image last night when I got home and it is actually worse than the previous version in that it spews errors so fast I can't read what they are saying. I might have messed up the implementation of the clock source or something :/ Good news is this weekend I have all the free time to devote to trying to fix it, which I have mixed emotions about.
 
A while back there was a clock rate parameter for the mmc card, I can't recall the name of it, but it was being flipped back and forth between 5000000 and 8000000 (Hz)... it gets put in config.txt on the vfat of the sdcard. It might be antiquated now, but if you think it is clock related you might try those settings.

Good luck!
 
I think you were on to something here. Apparently there's something in the "mystery files" that are included with the bootloader that certainly has an effect on things working. I think there's some setup that occurs in the bootloader before the kernel loads and some code in the bcm2708 Linux arch relies on it being set? It is hard to say because there's no source and no real changelog for the blob files other than things like "Fix timing" or some crap.

But in all this frustration, I manage to fix the "reboot" command because I was so burned out on trying various SD card items. I'm not sure how reboot works at all under Raspbian et al because it seems the reboot function isn't ever assigned unless it comes from the init section hardware tree and I can't follow that bit of magic C without understanding how the image is structured.

In any case, all of my cards now work, with the exception of a Transcend 8GB class 6 which reports an occasional error waiting for card sync, but appears to keep on trucking. If I raise the DMA sync timeout in the host driver to 300ms it stops doing it so it appears to me that this card just sometimes take longer than 150mS to write. The card has also been in constant use in my camera for over 4 years so it might just have some quirks by now. I'm going to leave the DMA sync the same as it is in the rPi tree though.

I'm in the process of rebuilding the entire system from scratch (after a `make dirclean`) and then I'll clean up my patches and post an image I'd like you to try on your SD cards that weren't working Evan. The image has other problems due to other things being in flux, like the 8192cu driver will lock up your terminal, but once the SD card issues are taken care of I can return to putting that driver back together.

I'll check back in in a few hours with the image.
 
Alright! Evan if you would be so kind to download this image, unzip it, and write it to your non-working SD cards and see if they work now and report back
http://home.capnbry.net:22674/rpi/openwrt-rpi.zip

Works for Me(tm) on:
Transcend 8GB Class 10 SDHC
Transcend 8GB Class 6 SDHC (reports timeouts, so not recommended, but seems to work)
Maxell 8GB Class 10 SDHC (noticeably slower than the Transcend class 10)
Kingston 8GB Class 4 MicroSDHC
G.SKILL 4GB Class 4 MicroSDHC

EDIT: and the 8192cu driver works but only if you insert the wifi dongle after the boot completes. Something about the OpenWrt wifi probe is locking the entire user-space Linux network subsystem due to something I'm doing in the driver.
 
Last edited:
You must log in or register to reply here.

 

Back
Top