Payphones used to be found on just about every street corner. They were a convenience, now replaced by the ubiquitous mobile phone. These machines were the stomping grounds for many early computer hackers, and as a result hold a place in hacker history. If you’ve ever wanted to re-live the good ol’ days, [hharte’s] project might be for you.

[hharte] has been working to make these old payphones useful again with some custom hardware and software. The project intends to be an interface between a payphone and an Asterisk PBX system. On the hardware side, the controller board is capable of switching various high voltage signals required for coin-line signaling. The controller uses a Teensy microcontroller to detect the hook status as well as to control the relays. The current firmware features are very basic, but functional.

[hharte] also wrote a custom AGI script for Asterisk. This script allows Asterisk to detect the 1700hz and 2200hz tones transmitted when coins are placed into the machine. The script is also in an early stage, but it will prompt for money and then place the call once 25 cents has been deposited. All of the schematics and code can be found on the project’s github page.

[Thanks mies]

Maker Faire Rome video interviews – “What have you built with Arduino?” – A couple of new protagonists for our short series:

• Arduino controlled Exo-Skeleton – Interview with Mel Li (Ph. D) about her latest project
  
• Vertical Automatic Garden – Automatic garden controlled by Arduino
  

See playlist on Youtube >>

For most of the Northern Hemisphere, winter is in full swing right now. That means long, chilly nights. We assume [LC] is in one of these climes because it seems like his bed warmer wasn’t doing quite a good enough job of getting his bed up to a reasonable temperature before he climbed in. To alleviate some of his discomfort, he hacked into the control unit and added some automation.

The original controller uses a mechanical potentiometer to set the heat level. [LC] added a digital potentiometer which he can switch to in order to allow the automation (using a real-time clock to handle scheduling) to take over control of the bed warmer. This also preserves the original functionality of the controller. There is also an Arduino involved which handles the override from mechanical to digital potentiometer when a capacitive touch sensor is activated. This means that when someone attempts to take manual control of the device, the Arduino can switch the override circuit off.

There is quite a bit of detail on the project site about this hack, including the source code for the controller. [LC] also mentions that this could be interfaced to the web to allow remote control of the bed warmer. This is a great hack, and also fits into the idea of heating the person, not the room.

Classes start tomorrow, so I spent yesterday making sure that the incubator control project was feasible. I had gotten the fan feedback control working well back in September, but I’d put the project aside for Fall quarter and only got back to it this week.  As a reminder, here are the previous posts on the project:

• Temperature-control project for freshman design seminar describes an idea for a possible project for the freshman design seminar.
• PWM for incubator gives a bit more detail on the temperature-control project.
• More on incubator design continues the incubator design.
• Thermal models for power resistors presents thermal models for 3 power resistors without heatsinks.
• Thermal models for power resistor with heatsink applies the simple thermal model to a power resistor with a heatsink, where it does not fit quite as well.
• PWM heater and fan talks about doing PWM for a fan and for a resistor as heater.
• PWM heater and fan continued continues the previous design work, reducing the electrical noise and making PI control loops for the fan and the heater.
• Controlling the heater and fan talks about progress on the control loops and gives the schematic for the circuit discussed in the two previous posts.
• Putting the heater in a box shows the physical layout of the partially completed incubator and discusses the (meager) progress today.
• Improving feedback for fan shows the working control loops, and compares on/off, hysteresis, PI, and PI with anti-windup.

Here is the interior of the styrofoam box, with the lid open. The 6″×12″ aluminum plate covers the bottom. The thermistor is on the left, propped up by a rubber foot, the resistor in is the center, and the fan is sitting on a foam pad on the right. (The foam is to reduce noise until I can get the fan proper mounted in a baffle.)

I left the foam out this time, which made for a somewhat noisy fan, and I still haven’t built a baffle—I’m still using the bent-wire-and-paper deflector shown in the photo. What I worked on yesterday was the software—since the temperature changes are fairly slow, it takes a long time to tune the control loops.

One thing I did was to try to reduce measurement noise further on the thermistor measurements. I now add 60  analog-to-digital readings. They’re 10 bits on the Arduino-compatible board (a Sparkfun redboard), so adding 60 still fits in an unsigned 16-bit word. I now get noise of about ±0.05°C, which is half the least-significant-bit of the converter.  I doubt that I can do better in precision without switching to a processor with a better analog-to-digital converter, though I could do digital filtering with a 1Hz low-pass filter to smooth out the remaining noise.

I copied the fan feedback control loop (with the anti-windup provisions) described in Improving feedback for fan for temperature control, but made two changes:

• I changed the integration time and K_p for the thermal control loop, since the temperature response is much slower than the fan response.
• Because of the huge asymmetry in the temperature response (the resistor and metal plate can heat up much more quickly than they cool down), I turn off the heater the moment it gets over temperature, no matter with the PI loop suggests, but I only switch to full-on when the air temperature is 3°C too cold. For the fan, I used a symmetric window around the set point for using the PI loop rather than full-on/full-off.

Here are some results from tuning experiments:

The blue curve switched to PI control at 23.5°C, the other two at 22°C. The green curve has pretty tight control over the temperature, but does overshoot a bit.

The initial temperatures were not all identical, because I wasn’t always willing to let everything cool down all the way to room temperature after each tuning run. I could only do about 1 tuning run an hour, which could pose problems for the freshman design seminar, as we don’t have long lab times—only the 70-minute lecture-schedule meeting times.

I continued the best of those runs with another step, up to 35°C, then let it cool down.

The step to 35°C has more ringing than the step to 25°C. I terminated the run before it had finished cooling, because the 32-bit µs timer wrapped around.

The cool-down at the end fits a 0.0069 °C/s line better than it fits an exponential decay to the ambient temperature.  If I do fit an exponential decay curve, I get a time constant of around 1975 seconds.

A simple thermal-resistance, thermal-capacity model is not a very good one for predicting how the system will behave, particularly since we’re not measuring the temperature of the large thermal mass (the aluminum plate and power resistor), but of the air, which has a large thermal resistance from the plate.  The time constant for the aluminum-air transfer is larger than the time constant for the electricity-aluminum transfer, which is why we get so much overshoot when we turn off the power to the resistor—the aluminum plate has gotten much hotter than the air, and continues to transfer heat to it, even though no more heat is being added to the aluminum.

Still, it is worth seeing what we get if we model the box a simple thermal mass and thermal resistor. The steady-state 35°C seems to need about 9W (PWM of 51/256) and the 25°C 3W (PWM of 17/256) with an ambient temperature of about 19°C, implying that the styrofoam box has a thermal resistance of about 1.9°C/W.

To see what is really going on, I’ll have to heat the box to 35°C, then start the cool down with a reset 32-bit timer.

Single-step warming from 16.9°C to 35°C. The steady state at 35°C is about 9.32W, for a thermal resistance of 1.8°C/W. The rise of 0.0451°C/s at 45W implies a thermal capacity of 998 J/°C.

Heating at 45W (9V, 1.8Ω) results in a temperature rise of about 0.0451 °C/s. This warm-up rate at 45W implies a thermal capacity of about 998 J/°C. We may want to adjust our thermal capacity estimate, since some of the 45W put in escapes through the box—maybe about 3–4W at the temperatures where the rise was measured. This reduces the thermal capacity estimate to about 910 J/°C.

The cool down from 35°C starts out as a straight line (about -0.0074°C/s or -26.5°C/hour), but gradually starts behaving more like the exponential we would expect from a thermal-resistance and thermal-capacity model.

The time constant for the cooling is about 1380s, but the initial cooling is too slow for a simple exponential.

The time constant of 1380 s, combined with a thermal capacity of 910 J/°C gives a thermal resistance of 1.5 °C/W, a bit lower than the 1.8°C/W I estimated from the steady-state power.

I continued the cooling (with the timer wrapped around) to see if I got a clean exponential at low temperature differences:

The exponential seems to fit well here, with a time constant of 2300s. Combined with the 910 J/°C, this gives a thermal resistance of 2.5°C/W, which seems a little high compared to the other estimates.

So I’ve made some progress on the thermal control loop (though I’d like to reduce the overshoot and ringing) and I have a crude model for the box: a thermal mass with capacity about 910 J/°C and thermal resistance 2±0.5 °C/W.

Still on my to-do list for this project:

• Consider using a PID controller for the temperature to get faster response without overshoot.  (If I can reduce the noise problem.) I should be able to reduce the noise with a digital filter, but I’m already pushing well beyond what I’m comfortable covering in a freshman class. Tuning a PID controller is even trickier than tuning a PI controller, which is already going to take most of the quarter to teach.
• Design and build baffling for the fan to get better airflow in the box. This might be a good thing to get students to do, particularly if we can get them to learn how to use the laser cutter. But even handsaws would suffice, given some thin plywood or masonite, some angle irons, and nuts and screws.
• Figure out how to get students to come up with workable designs, when they are starting from knowing nothing. I don’t want to give them my designs, but I want to help them find doable subproblems. Some of the subproblems they come up with may be well beyond the skills that they can pick up in the time frame of the course. The more I work on this project, the more I realize that I and the students will have to be happy with them having explored the options, without getting all the problems solved.
• Add changes to the cumulative error term whenever K_P or T_I are changed, to keep the PWM output the same after the changes—currently changing any of the control loop parameters adds a huge disturbance to the system. I don’t know how important this is—I’ve been doing my tuning of the thermal loop by recompiling, rather than by changing parameters on the fly. The quick changes were handy for the fan loop, where I could see things happening quickly, but for the thermal loop each experiment took about an hour, so there was no need for a fast parameter change.
• Research control algorithms other than PI and PID, particularly for asymmetric systems like the temperature control, where I can get fairly quick response to the inputs when heating, but very slow response when cooling. The asymmetric window for switching between on/off and PI control seems to have helped here, but there is probably a more principled way to handle asymmetric control inputs. Maybe I should ask some of the control-theory faculty for some pointers.
• Develop a more detailed thermal model with separate components for the aluminum plate and the air in the box. It may be worth adding another thermistor, taped to the aluminum plate, to monitor that temperature. The extra thermistor would also allow much tighter temperature control, avoiding overshoot on air temperature.

Is developing on an Arduino too slow? Are Phidgets too expensive? When might you use one or the other? Hackaday regular [Ken] breaks down what he learned from three experimental time trials.

The main development differences between Arduino and Phidgets are a mix of flavor preferences and some hard facts. The Arduino is open source, Phidgets are proprietary. Arduino requires a mix of hard- and software where Phidgets only needs (and only allows) a connection to a full computer but enables high level languages – it is expected to get the job done sooner and easier. And finally, Arduinos are cheap, Phidgets are 3-5x the cost.

The three time trials were common tasks: 1. Blink an LED. 2. Use a pot to turn a servo. 3. Build a pedometer. For [Ken], the Phidgets won in each of the three experiments, but not significantly: 37%, 45%, and 25% respectively. The difference is only minutes. Even considering time value, for most hackers it is not worth the cost.

In context, the advantages of a mildly more rapid development on the simplest projects are wasted away by needing to rebuild a permanent solution. Chained to a PC, Phidgets are only useful for temporary or fixed projects. For many of our readers that puts them dead in the water. Arduinos may technically be dev kits but are cheap enough to be disposed of in the project as the permanent solution – probably the norm for most of us.

[Ken] points out that for the software crowd that abhor electronics, Phidgets plays to their preferences. Phidgets clips together their pricey peripherals and the rest is all done in code using familiar modern languages and libraries. We wonder just how large this group could still be; Phidgets might have been an interesting kit years ago when the gulf between disciplines was broader but the trend these days is towards everyone knowing a little about everything. Hackaday readers probably represent that trend more than most, but let us know if that seems off.

[Ken]’s article has much more and much better detailed explanations of the experiments and the tradeoffs between the platforms.

If you enjoy watching parallel engineering, see the time-lapse video below for a split screen of the time trials.

[Andy] had the idea of turning a mixing desk into a MIDI controller. At first glance, this idea seems extremely practical – mixers are a great way to get a lot of dials and faders in a cheap, compact, and robust enclosure. Exactly how you turn a mixer into a MIDI device is what’s important. This build might not be the most efficient, but it does have the best name ever: digital to analog to digital to analog to digital conversion.

The process starts by generating a sine wave on an Arduino with some direct digital synthesis. A 480 Hz square wave is generated on an ATTiny85. Both of these signals are then fed into a 74LS08 AND gate. According to the schematic [Andy] posted, these signals are going into two different gates, with the other input of the gate pulled high. The output of the gate is then sent through a pair of resistors and combined to the ‘audio out’ signal. [Andy] says this is ‘spine-crawling’ for people who do this professionally. If anyone knows what this part of the circuit actually does, please leave a note in the comments.

The signal from the AND gates is then fed into the mixer and sent out to the analog input of another Arduino. This Arduino converts the audio coming out of the mixer to frequencies using a Fast Hartley Transform. With a binary representation of what’s happening inside the mixer, [Andy] has something that can be converted into MIDI.

[Andy] put up a demo of this circuit working. He’s connected the MIDI out to Abelton and can modify MIDI parameters using an audio mixer. Video of that below if you’re still trying to wrap your head around this one.

While [Ilias Giechaskiel] was waiting for his SIM900 shield to arrive, he decided to see what he could do with an old Nokia 6310i and an Arduino. He was researching how to send automated SMS text messages for a home security project, and found it was possible to send AT commands via the headphone jack of Motorola phones. But unfortunately Nokia did not support this, as they use a protocol know as FBus. With little information to go on, [Ilias] was able to break down the complicated protocol and take control with his Arduino.

With the connections were in place, [Ilias] communicated with the Nokia phone using a program called Gnokii — a utility written specifically for controlling the phone with a computer. Using the Arduino as an intermediary, he was eventually able tap into the FBus and send SMS messages.

Be sure to check out his blog as [Ilias] goes into great detail on how Nokia’s FBus protocol works, and provides all source code needed to replicate his hack. There is also a video demonstration at the end showing the hack in action.

It makes an Arduino look like a 555.  A 364 Mhz, 32 bit processor. 8 MB RAM. GSM. Bluetooth. LCD controller. PWM. USB and dozens more. Smaller than a Zippo and thinner than corrugated cardboard. And here is the kicker: $3. So why isn’t everyone using it? They can’t.

Adoption would mandate tier after tier of hacks just to figure out what exact hardware is there. Try to buy one and find that suppliers close their doors to foreigners. Try to use one, and only hints of incomplete documentation will be found. Is the problem patents? No, not really.

[Bunnie] has dubbed the phenomenon “Gongkai”, a type of institutionalized, collaborative, infringementesque knowledge-exchange that occupies an IP equivalent of bartering. Not quite open source, not quite proprietary. Legally, this sharing is only grey-market on paper, but widespread and quasi-accepted in practice – even among the rights holders. [Bunnie] figures it is just the way business is done in the East and it is a way that is encouraging innovation by knocking down barriers to entry. Chinese startups can churn out gimmicky trash almost on whim, using hardware most of us could only dream about for a serious project.

He contrasts this with the West where only the big players like Apple and Google can step up to the plate. Everyone else is forced to use the embarrassingly obsolete hardware we are all familiar with. But [Bunnie] wants to get his foot in the door. “Can we find a way to still get ahead, yet still play nice?” he asks.

Part of his solution is reverse engineering so that hardware can simply be used – something the EFF has helped legally ensure under fair use. The other half is to make it Open Source. His philosophy is rooted in making a stand on things that matter. It is far from a solid legal foundation, but [Bunnie] and his lawyers are gambling that if it heads to a court, the courts will favor his side.

The particular board targeted is the one described above – the MT6260. Even spurred by the shreds of documentation he could gather, his company is a 2-man team and cannot hope to reverse engineer the whole board. Their goal is to approach the low-hanging fruit so that after a year, the MT6260 at least enters the conversation with ATMega. Give up trying to use it as a phone; just try to use like the Spark Core for now.

He is already much of the way there. After telling you what is on board and why we would all want to use it, [Bunnie] shows how far he has gone to reverse engineering and describes his plans for the rest. From establishing an electronic “beachhead” base of operations to further probe the device, to X-rays, photos, diagrams and the beginnings of an OS. If this type of thing interests you at all, the meticulous approach and easy-reading of this tech teardown will surely impress and inspire you. Every step of progress requires a new hack, a new solution, a new ingenious way to pry information out.

We’ve featured some awe-inspiring reverse engineering attempts in the past, but this is something that is still new and relevant. Rather than only exploit his discoveries for himself, [Bunnie] has documented and published everything he has learned. Everyone wins.

Thanks [David] for the tip.

Read more on MAKE

[Gary Kildall] and CP/M are the great ‘also ran’ of the computing world; CP/M could run on thousands of different 1980s computers, and [Gary] saw a few million in revenue each year thanks to CP/M’s popularity. Microsoft, DOS, and circumstances have relegated [Kildall] and CP/M to a rather long footnote in the history of microcomputers, but that doesn’t mean CP/M is completely dead yet. [Marcelo] wrote a Z80 emulator running CP/M inside an Arduino Due, and he did it in such a way that it’s actually convenient and useful to use.

Instead of using CP/M disk images, [Marcelo]’s emulator emulates CP/M disk drives on top of a regular FAT file system. Drives are mapped to folders in the FAT file system, so a folder named ‘A’ will show up as the A: disk in CP/M. Drives up to P: are supported, the maximum number of drives available under CP/M. The BIOS resides in the root directory of the SD card, and so far Microsoft Basic, Turbo Pascal, UCD Micromumps, and Wordstar work just fine.

The Arduino project was built upon one of [Marcelo]’s earlier projects that put the CP/M emulator on Windows. The version for the Due works exactly how you think it would, with a serial connection and terminal emulator providing the IO, and the huge amount of processing power and RAM available on the Due doing all the heavy lifting.