Ah yeah I didn't push it to github. It's there now if you want to see the bad version. I've also removed the reset button in the upcoming version because it's not needed for programming. You can still short the one of the reset pins to ground if you need it, or use the software reset from the Pi side. But at least you can get an idea of what's needed for your board.
Ehhh...I am having trouble seeing the error. Are you talking about the part labeled "OKI-78SR-5" where the "KA7805AETU" was previously? I am looking at the 7/20/2012 6:01am schematic. It looks like you reconstructed the schematic from scratch kinda.
Yeah on the LinkMeter, there was only serial running to the AVR so to reboot it, you send "/reboot" and HeaterMeter pulls a digital line low just long enough for the the reset to activate. You're not supposed to do it this way but it seemed to work 90%+ of the time. The Pi schematic will have the the AVR's /RESET pin connected to the Pi's GPIO25 which allows us to hold reset as long as we like. The DO NOT BUILD schematic has it wired to the Pi's CE0 which proved to be unsuitable due to how the SPI drivers are coded (and probably all Linux SPI drivers).
Yeah the OKI-78SR-5. It looks right in that it is a pin-for-pin replacement for an LM7805, but the horizontal version of it is made to mount face down, which is the opposite of how the 7805 mounts so pins 1 and 3 are swapped. The LinkMeter and Pi schematics are mostly similar except with the serial interface, reset, and 3.3V shifting removed because the Pi version runs at 3.3V.
Yes! The buzzer is in and working in the latest HeaterMeter code but there's no web interface for it yet. The notification system will incorporate making an web request or sending an email (which can be sent to an SMS address if your carrier supports it). The LinkMeter version can't send email if your mail server requires SSL encryption, due to the size of the libraries required to do so, but the Pi version does.
The 7805 is a linear regulator and the Pi specs say it needs 700mA. Add on probably 300-500mA for a USB WiFi adapter and the HeterMeter draw of of to 50mA and we'd be way over spec for the 1A regulator. Also because it is linear that means you need a 1.5A 12V wall wart before you even include the fan. The OKI is a switching regulator with 90%+ efficiency at that power level up to 1.5A. If we assume all the circuitry is pulling 1.4A that's only pulling about 700mA from the 12V wall wart, leaving 300mA for the fan with a readily-available 1A adapter.
C6 and C9 are just for stabilization of the 5V and 3V3 power lines. All the major circuitry now runs on 3V3 except for the LCD which has its own decoupling so C6 seemed unnecessary. The Pi has plenty of onboard decoupling and power stabilization on its 3V3 lines and we're adding a second 3V3 regulator (which should halve the ripple) so C9 seemed superfluous. All the power caps are going to be replaced with low-ESR versions too so they should be able to deliver power faster when needed.
Yeah 47u was the standard Arduino capacitor size which is pretty high, the OKI datasheet says 22u input if using low ESR caps so I put that in place, knowing I could get 22u 10V caps in 7mm height. All the power caps have been moved now though so I can use 11mm height versions and all will be increased to 100u or greater.
D3 is there to half to protect against hooking up 12V in reverse polarity and blocks current the opposite direction. Its second job is to prevent the fan from using C4, and dipping the input voltage to the 5V regulator which would make keeping a constant output voltage more difficult.
Yes but really it is easy. I created some of the parts but you can find a lot of parts in the sketchup parts library. It is great because it is super easy to learn and you can see where you will run into issues. I checked the parts library yesterday and someone added a dimensionally accurate Raspberry Pi.
Did you just miss routing that wire? If so, it would be obvious if you were the one doing the routing because it tells you how many air wires are left. It isn't so obvious to someone who hasn't been staring at it for 11 hours.
Ahh yep AVR Pin 3 should be going to 10 on the Pi and AVR Pin 2 should be going to Pin 8 on the Pi.
How do you figure this stuff out? I realize your are a computer programmer and you have a good understanding on how these systems work but how do you trouble shoot this? Sounds like the oscilloscope has been helpful...maybe I need one just for fun.
The restrictions on where things had to be meant that things had to be in non-ideal places. I've gotta run SPI bus to the AVR, the Pi, the RFM12B and the ICSP. 6 data lines to the LCD around those from the shift register. Serial to the FTDI, Pi, AVR. 5V for the LCD on both sides of the connector as well as the Pi. Blower support components before the diode. It was all too much for me to route manually so I would export the board, load it in FreeRouting, fix the rules because FreeRouting hates you, start the router then wait 10-15 minutes. Move a couple of components around in EAGLE, repeat.Originally posted by Dave S (GeoDave):
Did you just miss routing that wire? If so, it would be obvious if you were the one doing the routing because it tells you how many air wires are left. It isn't so obvious to someone who hasn't been staring at it for 11 hours.
Yeah I sent the board off to fab without verifying this. It worked on my breadboard setup because I had it right there. Also my ground was good on the breadboard. I'm so glad I built that first and got hmdude working because this would have been a real pain to debug from the software side only.
I reduced the equation by removing the HeaterMeter from the Pi, it still runs standalone if a Pi isn't attached. I have an LED with a resistor soldered on one of the legs and I just dropped that into the ICSP header between SCK and GND. It should blink a couple times when Optiboot flashes the LED (which happens to be on the SCK line on the Arduino platform). Once HeaterMeter boots, when it updates the LCD it blinks the LED as data is transferred to the shiftregister (it blinks at like 2MHz!). That was happening so I press-fit an LCD into the header and wedged my finger into it juuuuuuuuust right and every couple boots the LCD would say NO PROBE. Connected it back up to the Pi and presto change-o the LED stopped blinking. For good measure I looked at it in the scope and SCK just stayed low the whole time after bootup.
I don't feel like it does a very good job. I try to keep the via count low so theoretically someone could build one of these boards at home without having to run 50 handmade vias, which is really annoying. It probably doesn't make much difference in the final product but I spend a lot of time looking at the traces and deciding if they meet my level of satisfaction-- going straight enough or too close to that other signal. I like to think that it produces a board that is more fault tolerant in manufacturing but I really doubt that it does.
