OpenAccess 3.0 hardware quirks

The Openaccess 3.0 shield is kinda old, but it’s actually pretty good.  I have quite a bit of experience using it so I think I’ll talk about some of the oddities in it here today.  I’m going to start with a silkscreen nit pick and segway into some other things.  You may think I spelled ‘segue’ wrong, but what you can’t see is that I’m balanced on two wheels right now.

Incorrect placement

Ignoring, for the moment, the unpopulated relays and screw terminals take a look at R47, 71, 72, and 73.  Those all appear correct and well tacked down.  I will also not that nowhere on this board do silkscreen deliniators for components reside at a 90* angle from the components themselves.  Nowhere except here.  The yellow and black wires connect to the battery voltage input of this board.  The entire row there is for alarm sensors (which also go into analog pins) but the last one is set up with a voltage divider so it can be connected to the battery the OpenAccess runs on (if you run it off a battery that is).  For the longest time I couldn’t make the simplest part of this board work, the battery sensor.  Eventually I traced the circuit to see that it didn’t do anything.  Checking the board layout (which isn’t provided in pdf or anything so you need eagle to read it) I found that two of those resistors were in sideways.

I stand by how I assembled that board and will insist that the error lies with the board design.  With that identified and repaired I finally got a good read!

There, now it reads correctly.  The only thing is there’s no reason I can tell to have that separate from the input voltage.  This has a nice switching regulator onboard and runs happily right on lead acid batteries.  I decided to jumper the input to the voltage divider so that I could read the voltage that was feeding the board power.

The further modifications I made are these:

pass-through to use the protection circuit through the unified cable that goes to the front panel

Parallel port on the right, level shifter in red goes to the tiny 0.1″ screw terminals for 3.3v serial (skipping the usb/serial converter), and the screw terminals for the exit button

The cable for the dot matrix printer (both polarity by mistake)

The round cable goes to the front panel, the B-wire goes to a beagle bone for network connection and control

That covers the modifications I made to the board.  Let’s go over the rest of the hardware:

Reset button and header for the same

i2c rtc and eeprom circuit (big ol’ eeprom too)

voltage divider and zener diode on each alarm sensor pin

This is the protection for the wiegand readers, resistor dividers and zener diodes

This is the rs485 circuit, jp1 connects the input to the output through a resistor

This is the power section for protecting the rest of the board from a flaky power supply

Here is our switching regulator, that big resistor is the current sense one of a very small rating

This is the relay driving circuit, it goes through a buffer/driver and has individual LEDs

So, admittedly this is heavy on pictures and light on explanation.  Most of the explanation will be in the article that describes the code.  At some point I’ll tie all these articles together.

 

 

 

 

Wiegand keypad

So far with the OpenAccess system I’ve talked about the rs485 terminals I tried to use, a clever low pin count display and keypad, the final display and keypad controller I built, and the ability to log to a dot matrix printer.  Now I’ll talk about another I/O system that I tried but didn’t end up going with: a fully wiegand keypad and rfid reader.

I don’t think I’ve discussed wiegand here before.  This protocol is like a cross between rs232 and rs485, but originated with magstripe readers.  I’m going to spin you a tale that may not be entirely accurate, but I’ll tell it in such a way that it could be.  Back in the day when magstripe ID cards were starting to be used for everything there would be readers on tons of doors in every building of an entire campus.  This could be a government facility, a college, or just a security-conscious private company.  Having lots of distributed computers doing local processing or encryption and all sending data back along the same tcp/ip based network is how we do things now.  There was a time that paying people to run lots of wire was cheaper than put in micro computers everywhere.  In these dark times the magstripe readers would be at the end of a long cable, untwisted because that too cost money.  We have been sending high voltage (the spec doesn’t specify voltage, but I’ve seen as high as 30V peak-to-peak) rs232 from building to building for a while, but with no control lines and no communication back to ask for a re-transmit there needed to be a way to get the data transferred correctly the first time and do it cheaply: wiegand was born.

Wiegand is digitally signaled by sending the ‘ones’ down one line and the ‘zeroes’ down another.  This is effectively like having a deferentially signaled line, except the timings are such that both lines are low between bits.  If you relax your timings a bit you can get away with using just one of the wires (I don’t know anyone else who does that… GM) but it’s not generally good practice.  There may be no way to ask for a retransmit from the microprocessor, but you can certainly ask the user.  My wiegand readers have LED and buzzer outputs that can be driven by the controller.  I said this was born of magstripe cards, lots of magstripe readers put this out natively, or they do inside between some controller chips.  In order to keep up with the changing security concerns facilities went to rfid cards, but due to rampant and perpetual cheapness they kept the same backend hardware, software, wire… and just slapped these readers on the front which spit out the same codes as the magstripe ones.  I may put up some documentation I have about probing a facility in transition later.

Now that we know what wiegand is (and hopefully you hate it like I do) let’s talk card length.  The cards I use are 125khz, unencrypted, and have a 26bit code in them.  There are ones up to 34 or 37 bits, some that use different frequencies, encryption, and some that have dual frequencies for compatibility.  There are no cards as short as 4 bits, that would be crazy, you could only have 2^4 combinations.  What would you possibly do with 1/16 possible combinations.  Oh, right, the keypad has 12 positions.  So, in order to read this keypad you have to poll for wiegand data and if you have accumulated 4 bits of data and after a short while are accumulating no more then you have a button press.  Now, if you don’t know you’re looking for button presses differently you may press 6 buttons and find yourself having read a card that doesn’t look like any card you’ve seen before.  Could the designers of this keypad put in 16 full 26 bit streams that correspond to key presses? yes.  Did they? No. Is this a good design practice? You decide.  If you want to be all exact about it you can start a timer when you get the first interrupt and figure out if there’s an unusual pause between the fourth and fifth bit which would indicate someone pressing buttons, you could also just poll constantly and assume that the buffer will be exactly 26 bits or 4 bits when you read it because of how fast you poll.  I split the difference, if the buffer has more than 25 bits in it I assume it has a card, remove 26 bits, act on it, and check again.  Else if the buffer has exactly 4 bits I assume the buffer has a button in it and read that.  I make no provision for polling the buffer while the interrupts are filling it up and that’s not been a problem for me yet.

There’s how to read the wiegand keypad.  If you ever have trouble feel free to throw it away and get a real protocol before calling me.  Or call me, I’m not usually busy.

 

the keypad test code is here

Arduino keypad and display

“This project was originally started as part of the i3 Detroit OpenAccess control system for RFID entry.  I promise I’ll write an entry on that soon, but I’ve got to shake down all the bugs first.”  That was two and a half years ago.  I’m going to do a write up of all the aspects of the system I designed even though I have no intention in actually implementing this system.  The reasons I have for not using it are basically: I won’t be the only person responsible for repairs/debugging, I won’t implement any more features I don’t think are useful, no one has stepped up to learn about it.  The system it’s replacing is an off-the-shelf rfid mag-lock with keypad and while that is lacking a lot of features that would be helpful I am not moved to change anything because the benefit of features vs. the cost on my time is not worth it.

The first aspect of this system is the front panel controller.  My re-implementation of the OpenAccess system had to start with adding the ability to enter PINs.  Now, there are plenty of other systems that hackerspaces use or have built but a minority of them use PINs, it just seems that they either choose a more interesting method of second factor in their identification or forgo it entirely as being un-needed.  Considering the physical part of the security is usually the weakest link in the system most people have decided that the brick next to the window makes a PIN to go along with the key sorta pointless.

old schematic, not using i2c for the final design (and am setting contrast locally)

Since I rewrote everything from the ground up I got to choose a control panel for the outside.  Originally I wanted to use the rs485 control panels but talking to them ended up being cumbersome and the more I used them the more I hated rs485 (at least use rs422, it’s full duplex).  This control box has 12 volt power, ground, wiegand signals for the rfid reader (the buffered inputs are on the OpenAccess main board) a single ds1822 temperature sensor, rx and tx pins to the atmega I’m using, and (according to my schematic) the contrast pin for the lcd.  I can see from my code for driving this display that I am controlling the contrast locally (actually, for outdoor use a VFD would be much better in michigan winters and as everyone knows is sunlight visible).  I am not reading the temperature locally, although I have the spare pins to do that.  You can see for the RFID reader I put an orange LED and a western electric warble buzzer on the output pin of the rfid reader.

Old processor

Adapter!

This code started out as an i2c display and keypad that used an attiny.  I thought that if I used someone else’s code I could avoid having to debug it.  WRONG! Let’s start with this: if you ever try to use i2c over a cable, just don’t.  Inter-integrated circuit communication should be done on a single board.  If you have to go off board use SPI or UART.  My experience with that i2c controller wasn’t great.  I think I might have been running up against memory restrictions on the attiny2313, but considering a pro mini from china is about as cheap as sourcing a single attiny chip here…. I replaced it.  My code for the display uses serial, good old fashioned reliable serial that takes no special tools to debug or talk to.

The code I have works like this:

• read for serial commands and do any of them
• if a key was pressed, return it over serial (no line breaks)

That’s it.  The commands are for brightness, contrast, display, and display line.  The display command works from the last cursor position and the display line command rewrites the whole line.  That is exactly how simple this code is.  The contrast and brightness are done with PWM from the arduino pro mini, I use a keypad library and serial command library (specifically modified for the 328 as opposed to the 2560 which I will cover in a later post).  I fully support the modularization of your software, this extends to the modularization of your hardware.  I could run a thicker cable and have all the keypad and lcd pins run back to the main microcontroller, I could even use local chips to multiplex those pins, but having a second brain at the other end able to take human-readable commands just made it so much easier.

New processor

Code is here.

Pictures and schematics are here.

Wheelchair robot

Back in college (yeah, those were the days) I was in a hackathon with a couple other guys.  What we decided to do was to build a robot platform out of a wheelchair.  While researching for this article I found out that we are not the only ones to do that with this style wheelchair, but I think we implement the most functionality.

We chose to interface with the existing controller since it already does what we want.  Power was not an issue as you can see the battery voltage is brought right to the controller and helpfully labeled.  The inputs and outputs were:

• in: power state (using an analog pin and LED)
• in: power switch (manual control passed through our code)
• in: speed up switch (manual control passed through our code)
• in: speed down switch (manual control passed through our code)
• out: power relay (controls the power switch on the pcb)
• out: speed up (controls the speed up switch on the pcb)
• out: speed down (controls the speed down switch on the pcb)
• out: speed/speed2 (sets the position of the virtual analog stick)
• out: turn/turn2 (sets the position of the virtual analog stick)

In addition to these we also used the usb-serial converter on the serial lines to communicate with the laptop.  Through incredible self restraint we didn’t implement the horn functionality.

Here is our modified controller.  You can see the joystick connection is modular so we could probe the lines in circuit before connecting our controller to them.  That proved absolutely essential because this controller is a little smarter than you might imagine.  The joystick has 2 separate potentiometers for each axis which we drive with identically controlled pins on the arduino pro mini.  The controller also throws an error when the virtual joystick goes too far out of the range of the mechanical joystick.  we have capped these pwm outputs using a helpful map function:

speedOut = map(speedVar, 0, 1023, 50, 210);
analogWrite(SPEED_OUT, speedOut);
analogWrite(SPEED_OUT2, speedOut);
turnOut = map(turnVar, 0, 1023, 50, 210);
analogWrite(TURN_OUT, turnOut);
analogWrite(TURN_OUT2, turnOut);

This allows us to work in 1024 increments of turn and speed while knowing we won’t trip the internal protections against an unplugged or shorted joystick.

The code written here is non-blocking and runs in a continuous loop.  It checks to see if any switch is pressed and does the corresponding command if needed.  It then checks to see if there are any serial commands that need executing (I’ve used this serialcommand library before).  Once it executes any needed commands it sets the virtual joystick based on the internal variables stored for the position.  It checks to see if it has been more than 3000 loops since the last command given, and if so it re-centers the joystick (a crashed python program sent it driving off since we no longer had a spring return joystick).  The commands it takes are :

• TURN [0-1023]
• SPEED [0-1023]
• SPEEDLEVEL [-1,1]
• POWER [0,1]

Turn and speed set the joystick position (512 is center), speed level pushes the relevant up or down speed button (which just scales the joystick, increasing or decreasing the max speed), and power turns on or off the wheelchair controller (not our controller).  Since these commands just push buttons it is not possible to know if you are at the max or minimum speed (we did not read any more LEDs, but you could).  We did, however, implement the power LED.  When you want to turn on the controller it checks to see if it is already on and then sets the joystick to center, presses and holds the button for 100ms, then releases the button.  This is also part of a safety interlock to keep the wheelchair form just taking off when turned on.

The power connector passes 12V for charging and is labeled as such. I didn’t do that part, I promise.

The power connector passes 12V for charging and is labeled as such.  I didn’t do that part, I promise.

The next bit of software I didn’t write.  We interfaced this robot with a laptop and a kinect for doing depth mapping.  You can see that code here and your interpretation is about as good as mine, but I will try.  I will say that this code is sending speed, turn, and power commands as one even though I am processing them individually.  The speed up and speed down are not used (we used the manual switches in the robot).  The logic in the python code looks at a center depth, a left and right side.  If the robot is clear to move forward it does, else it goes left, else it goes right, else it backs up.  The behavior is very simple and the movements around our oval-shaped hallway were interesting.  There’s enough lash and randomness in the mechanics of the wheelchair to make sure it never gets stuck even without more complex self-correcting code.

That’s it.  How to make a wheelchair based robotics platform and how to interface that low-level arduino control to a python script.

pictures are here.

code is here (forked in case he wants to bring it down)

2.4Ghz analog camera scanner

This story has a part ‘back in the day’ and a part just a couple months ago.  Let’s start with the most recent part.  I decided that I want cameras around my house.  I didn’t say in my house, I said around my house.  I would like to be able to see my front yard, back yard, driveway, and maybe even down the street a bit.  I want cameras inside, but this is absolutely not the way to do it.  I came by a number of analog cameras with 2.4ghz transmitters, but the receiver I had used analog tuning.  I never worked out whether it would pick up all 4 channels of camera (there are 4 in the standard I’m familiar with) or just fine tune on 1 but either way I decided that using analog tuning is harder than it needed to be.  I went on ebay and picked up a 4 channel receiver with a switch going between channels.  With that I got all 4 of my cameras on different channels and able to be picked up by the receiver.  In the process I found a camera outside that picked up my hackerspace (probably by the landlord based on where it was and was pointed).  Now, even if I didn’t already not want these cameras inside… I would like to think this would have done it.

Before I go on with this hack (which is, as always, half finished) let me bring you back to my inspiration for this one.  If you look up the origination of the term ‘wardriving‘ which is what I grew up doing (driving around picking up people’s wireless networks and using/breaking into them) you will find ‘wardialing‘ which is basically robo-calling for modems.  This was popularized (if not originated) by the movie WarGames because before Matthew Broderick was doing his best Gene Wilder impression, he was impressing girls with his computer skills.  This is a different kind of automated scanning attack, the one I’m thinking of is ‘warspying‘.  Eleven (!) years ago Systm launched and had an episode with a howto for building a handheld unit for detecting and displaying unencrypted wireless cameras.  I wanted to use that technique to drive this switch from a raspberry pi (or any other computer with gpio).  Where they used a small pile of discrete I/O to accomplish a dedicated scanner I used a simple demultiplexer, a 74155, to control 1 of 4 lines with 2 GPIO.  Since I only need one line grounded at a time I can use this technique to save pins.

You can see from this switch diagram (or the description in the Systm video) that the switch has 6 pins and 4 positions.  If you ground the two center pins then you ensure that one of the outer 4 pins is grounded in each switch position.  Rather clever for what would otherwise have been a more complicated mechanism. That being said, this doesn’t scale very well.

I really wanted to replace the whole board here, or at least make the unpopulated stuff work but that just never happened for me.  For anyone else with one of these modules, now you know what’s inside so you’re prepared before you go tearing it apart.

Now you can see how I made a camera receiver interface with a raspberry pi.  If you send 00 out two pins you get channel 0 of video, if you send 01 you get channel 1, same for 10 and 11.  Until this actually gets used with GPIO I have set up a 2×3 jumper block with power down one side, ground down the other, and the two data lines in the middle so they can be pulled high or low.  There is no ‘off’ since that wouldn’t matter, the video capture card is connected straight to this module and there is no need to switch it out for anything else.  If you needed to it could be done with a 4051 analog mux though.

pictures related to this project are here.

TTL POV globe redesign (part 1)

Back in college I built a POV globe.  I was really not happy with it, mostly because it’s something I felt could be done with discrete hardware more easily.  The first part to getting the POV globe in chips is to work out how to store the lines and retrieve them.

The big plan includes using a bigger chip with bank switching for animations and maybe even higher bank switching for going between animations.  This means that we need X address lines for 2^X lines, Y address lines for 2^Y frames, and Z addresses for 2^Z animations.  Eventually I would like to have a dynamic clock divider so we can have a variable speed motor and still scale the line frequency to keep the image all displayed in one revolution.  For now I have put together a clock out of a 555 timer, and decoders for the 28C64 EEPROM made from 74LS161 chips.  The EEPROM was programmed using the TL866 programmer to a sequential pattern as an example.  You can see that this chunk of the circuit iterates through the addresses and the outputs are tied to LEDs.

<video showing reset circuit>

<video showing addresses counting up>

<video showing changing the clock speed changing (blink pattern in the chip)>

Next time maybe I’ll have a dynamic clock divider circuit.

here is the code.

Door Iris

At i3Detroit we had a door (as seen it the scrolling, scaling web 2.0 bliss that is i3’s main page [just go to the wiki for important stuff]) that frequently got opened into groups of people standing by the front door.  The groups stand there because despite this door always having existed someone decided that a good bottleneck for people is right there, in the way.  Other hackerspaces have paperwork filled out elsewhere in their space, places where you can sit down even, but not us.  I chose not to solve the problem of people congregating because it didn’t seem interesting.  Instead the problem to be solved was that the door was a bit too opaque.  We could, of course, put a window in the door.  The issue was that the door worked fine most of the time as its old opaque self, and we really only needed a window then there were people on the other side of the door.  An on-demand window.  A mechanical iris for the door of course.

This idea and the plans to laser cut it were blatantly stolen form the internet.  I don’t remember where I got the file I ended up using to cut it out, but it is hosted on i3’s wiki here.  The thing that we added to that is a car window motor spline.  This particular spline comes from a motor used by a FIRST team some years ago.  To model it I just drew 2 concentric circles in inkscape, did some math to calculate the offset of the spline edges from the center, and traced it out.  I provide it here if you happen to have the same motors we had (I don’t remember what brand or model they were.

The PIR sensors are pretty standard, but I wanted to jazz them up a bit.  That, and it’s easier to debug if you can see what’s going on.  I was inspired by the ‘electric eye’ description in stories about old-school home automation and added a FET, resistor, and orange LED to light up the shell of the PIR sensor whenever the output is triggered.  Based on my knowledge of historical electronics I would guess that the ‘electric eye’ in those stories is a big freakin cadmium sulfide cell that they pass motor current through.  That being said, tuning one of those systems is no way to have a relaxing weekend if you have a deadline anytime soon.

So now we have sensors for people and an actuator for the door.  Now we need limit switches.  My preferred way of detecting the limits of this mechanism is to use limit switches.  You could use motor current, but that is likely to vary over the life of the motor, wire, solder joints, etc. You could implement a rolling boxcar filter to pick out where the current should be based on the assumption it will be changing slowly over time but that relies on good sturdy mechanical connections and not much slop.  It’s also much harder to program, and harder on the wooden gears needing to put stress on the whole system to know when to stop.  The key aspect of using limit switches instead of motor current is that it does not stop if you put your finger in it.  I am of the opinion that if you put your finger in it then you must not care about it enough and deserve what happens to you.  I have also intentionally put my finger in it and with the motor moving on 5 volt power it doesn’t hurt that much.  To address how to fix this (because if the motor does not reach the limit switch then it never stops) I made the code so the iris opens upon reboot.

 

With limit switches you can tell when you’re closed, you can tell when you’re all the way open, but you cannot detect an intermediate state.  This becomes more complicated when you talk about having two limit switches and two triggers on the same gear.  Because of how far the gear rotates to make a full movement of the mechanism it was not convenient to have one magnet and hall effect sensor.  I decided to add 2 sensors and two magnets.  This means that there is one position where the drive gear and ring gear can meet in order for the limit switches to work.  This gets tricky if anyone dis-assembles the mechanism and moves it by hand.

The only remaining question was how to power the motor.  It turns out that the motor that’s designed to run at 12V works great at 5V.  The problem with using a logic and motor power supply together is that when the motor browns out and resets the microcontroller you get a nice infinite loop of opening and closing.  A nice chunky power supply solves that problem.  We switched the motor with relays because the coil current draw isn’t an issue and dissipating the heat a FET would generate is also not how I like to spend a relaxing weekend.

<laser cutter porn>

The mechanical assembly was done with chrome 1/4-20 hardware, washers we lasercut out of a single thin sheet of polyester, coconut oiled wood (which we hastily cut on the wrong side, it’s not a symetrical design) and brass flat head wood screws.  The scale was wonderfully coincidental, we were given the porthole which had an ID of 7″.  When we scaled that to the whole project it turns out the 1/4-20 hardware worked great.  The porthole got a lasercut sheet of acrylic to replace the non-existent glass and a translucent ‘i3’ vinyl logo in the center.  The arms that move even got a real gold leaf treatment.  The mechanical build went smoothly and waited for a motor current based control board.  When that didn’t appear I put it into permanent install with my code and limit switches.

The code is supposed to do as follows:

10 open the iris

20 close the iris

30 if either of the sensor lines goes high

40     open the iris

50     stay open until 2 seconds after both sensor lines go low

60     close the iris

70 goto 30

It bounces around a bit and one of the sensor wires has fallen off inside the door (don’t use connectors when you can fit an iron in there, seriously) so it only opens from movement outside.  It’s not perfect, but it’s perfect enough that no one has been motivated to change it in the year and a half since we made it.

pictures and videos here.

code here.

Drill chuck replacement

For any of you plagued by modern power tools, I have a reminder for you.  Even if you have to get a drill to finish a project right now and your only option is a speed chuck there is still hope.  Just because you had to buy a new tool doesn’t mean you need to be stuck with crap forever, upgrade it! By using a hammer, a large allen key, and some stiff impacts (don’t burn up the motor trying to do this with the drill) you can remove that new crappy chuck and put on a nice old Jacobs chuck with a key.  Gone are the days of skinning your palms when you try to get a drill bit in and out.  Or the instances when you just can’t get enough torque to keep that hole saw from spinning.  With your newly installed chuck and key you have the needed mechanical advantage that makes a drill worth using.  Ever wonder why not even the cheap companies use a keyed chuck on their larger models? That’s right, you can’t get the needed torque.

Hacked LCD (given composite input)

There was a time that I would take any display that I could get my hands on and try to find a composite video signal inside it.  With that information I could modify it to take composite input from my source and I’d have a portable little lcd that I could use with my commodore 64, or raspberry pi, or… game console… this was before the C.H.I.P. or other single board computers with composite became popular.  That technique is still useful today because of the continued prevalence of composite video and the ubiquity of displays that can eat it somewhere inside.

The patient is this audiovox under-cabinet television and radio.  Let’s have a look inside.

My that’s a lot of empty space! if you look closely you can see where a dvd module would go, if this unit had one (!).  I have already hacked this one so there are some things missing.  First, you can see a lack of any RF cans full of tuning equipment, so this can’t pick up video or audio over the air anymore.  I’ll show you a picture of the back soon, but for now look at how sparse the board is (there’s more underneath but look at the unpopulated bits up here first).  There’s a section off to the right that looks to me like a modem.  I don’t know what that was for, really.  If anyone has an idea please let me know because I’m interested.  There’s also a set of unpopulated parts (including what looks like a mains section ) on the left side of the board.  That could be if there wasn’t an off-board power supply, I’m not really sure.  Looking at the parts that are present you can see a long DIP chip with some hefty capacitors, that’s the audio amp.  The connectors just above it in the picture go to the speakers.  The pole of odd stuff at the top of the board is the power supply for the VFD, there’s nothing else that would need those parts on this board.  Let’s rotate.

There’s my hack and you can see where the radio and TV tuner went.  You can also see I didn’t drill those holes, there was an option on this model to come with composite input.  I didn’t try to reverse engineer the extra feature, I just removed the other stuff and used those inputs.  Rotate again.

You can see there’s a bunch more stuff unpopulated, and the section I thought was an unused mains power supply says caution.  Enhance.

Wrong section but I can talk about it anyway.  I find this a little strange, I don’t usually see atmel ICs in the grade of consumer electronics I dissect.  I will point out I could reprogram this to add features and basically do whatever I want.  I would rather… no, this is public and if I use some colorful example someone will use it as evidence to convict me of something.  Let’s just say I won’t be doing that today.  Reposition.

Ok, here’s where I patch in the audio.  I tapped off two pins that I found near the amplifier and I removed the 4051 feeding it so that only our audio is heard.  Reposition again.

Here’s a tricky one, I actually fired up a video game, took a probe, and started injecting composite anywhere on the board I thought likely to work.  I could have probably guessed as well, but this worked really well, especially with no tuner trying to drive the screen black.

This is inside the LCD itself, there was a board to control brightness, contrast, and stuff.  You can see the ribbon that goes between the LCD and the body, I didn’t want to touch that.  So there you have it, that’s how I repurposed a thrift store screen into a portable LCD for use with my raspberry pi.  If I desired there’s plenty of room inside for the pi and a bunch more hardware, the power supply would work well too.  This currently tests composite cameras for my insecure 2.4ghz camera setup that I’m planning around (not inside) my house (post coming soon).

All photos here.

UPDATE 12/19/2022

I finally decided that this is too big and annoying of a form factor to use much. As such I reverse engineered the cable between the screen module and the bigger under-cabinet unit.

I couldn’t find an off-the shelf controller to drive this screen, which is fine because it wouldn’t fit as nicely in this shell. The connector across the top is as follows:

12v, gnd, composite video, unknown, 3v?, IR data, 5v for IR

Interesting thing about this is the only ground wire on that connector is the shield of the cable that carries the video. I wouldn’t have designed it that way… That being said, after hooking up 12v, ground, and composite in I have a working monitor.

I did lose audio, but I think I have a solution for that. The female barrel jack cable I used is actually a barrel jack splitter that I cut one male end off. I fed the unused end back out as a 12v pass-through cable. With this I can design a simple stereo audio amp and power it from that barrel jack. I certainly have some esoteric audio amp chips that warrant a run of 5 specialized boards to use them.

Now, no one point out that the sharp tr3y31m can have rgb in, I’m pretty done with rgb right now.

custom arduino sound board and example

So, this is going to get strange if I’m blogging about things I’ve already blogged about.  I’m reaching pretty far back, but I think this is still new to the world.  A while back I designed some boards, which I know is very uncharacteristic of me but I did it and they worked fine.  I was surprised it worked the first time considering I took the schematic for the arduino pro mini, the adafruit wave shield, and a stripped down example circuit for the TPA3116D2DAP.  I’m going to say right now that this audio chip is just silly, especially for my design.  This chip can run in stereo or mono mode, and in mono and properly heatsunk it can drive 100W of power.  I am using it basically at the lowest end of the power curve, at 5 volts where my power supply sits and that puts out about 3 or 4 watts of power.  If I was using about 12 volts it’s be a lot more efficient, but I really don’t care that much about efficiency.  Prototyping that chip was fun, and in the end I looked at the example circuit for the output and figured that since I didn’t stock any inductors they must not be all that important and I omitted them.  Whether or not you agree with the logic, the circuit worked beautifully.  To solder it to a board I put a square of 9 vias and used it as a heat transfer pipe to melt the solder on the power dissipation/ground pad on the bottom of the chip (all you need is a pencil iron, it can solder anything if you’ve got the finesse).

Building your own power amp with these chips is really easy and I highly recommend them in new designs.  Given that my debate was over how to match the power of an lm386 at 9v with a different audio amp at 5v I think I succeeded.  The rest of the board layout went well.  I used a full size SD slot because it’s easier to get full to micro adapters than the other way around.  I broke out all the pins in a square around the package since I didn’t want to bother with the arduino pinout.  The FTDI header is upside down because it was easier to wire that way, there was no provision made for the height of the capacitors but they lay flat just fine, and the switch footprint doesn’t match because I didn’t trust the measurements the manufacturer gave and didn’t have time to get them here to measure myself.  All that being said, the boards worked beautifully the second time.  The first time I found that I got the atmega328 not the atmega328p.  Basically it means that you have to either rewrite the definition to include this fact or run -F in your avrdude command.  I copied the pro mini config file and tweaked one value to create a new board definition.

The wave shield and library are a little… primitive.  Don’t get me wrong, it’s fantastic but it basically hasn’t changed since the arduino was through-hole.  The whole thing relies on just moving chunks of WAV file to the ADC at a regular rate set by the interrupts.  There’s basically no more smarts to it than that.  This means a low part count, very common parts, and editing the library is easy for newbies to coding.

In addition to this  I added a lipo charger (which does not work if you attempt to charge and use it at the same time, from the same source, without diodes) and a lipo fuel gauge.  The fuel gauge may just be a watchdog that monitors the voltage but it’s easier than writing the algorithm myself.  Now I’m up to: arduino, SD input, amplified sound output, battery, charger, monitor.  That’s a pretty self-contained system.  Now on to the tasks I can preform!

The plan was to make the elevator make a sound when moving.  tapping into it wouldn’t be an option because this was actually entered in a hackathon in college and telling them I did that wouldn’t go over well.  I tried discretised integration, I can’t sample fast enough to make an integrator that doesn’t drift.  I thought about using an analog accelerometer and op-amps but I didn’t have any and then I’d be tuning drift with trimpots instead of #defines.  I could also design a completely analog self-zeroing system but I’m lazy and didn’t have the parts at the time.  What I did was implement acceleration bump sensor.  I’d sense a blip either up or down and assume I was in motion for the rest of the time until I felt a bump in the other direction.  This works except I make too many assumptions about how long and intense the bump will be.  There’s play in the elevators I used so jumping on the elevator without it moving is enough to set it off.  I did, however tune it so that with no overly strong exceptions it would work consistently.  I think a gyro would have made this more robust but, say it with me: I didn’t have one at the time.  It’s easy to implement something if you have all the right parts, the challenge is in the hack.

Here’s the video

Here’s the code

Here’s the board

Here’s the pictures