After trying Resin.io briefly with a SomaFM Streaming Application, I was eager to experiment more with their cloud deployment platform. Maybe some new hardware, maybe some more complex project… In the end, it became a little bit of both: here’s MrEdison, and portable IRC chat display based on Intel Edison.
The idea came from the fact that we have an IRC channel for the Taipei Hackerspace, #taipeihack on Freenode, just it is not very well (or rather: at all) frequented by people. I wanted to break that channel out of the computer, and put a physical window to it in the ‘space, so people can see what’s going on, and hopefully want to get on too!
There are all kinds of toys and fun gadgets around the house for most people that might work or be broken, but either way most people wouldn’t know how do they work inside. For example take this solar powered Tibetan prayer wheel. There are many of these out there, and found one at home lying around as well. It didn’t seem to work, and thought why not take apart to take a look?
The inside of this Tibetan prayer wheels is pretty straightforward: taking off the bottom cover out come two ballast stones, and drivebox with a solar panel hanging off it. The drivebox is connected to the prayer wheel outside via a rectangular shaft to turn it.
I have signed up to support it for two main reasons: it’s a Taiwanese project (Skytraq, the company behind Navspark is in in Hsinchu city in Taiwan), and I haven’t seen anything about Beidou before.
They barely made the campaign, but it’s not for the lack of quality. There were a lot of updates during and afterwards as well as the project was developing. Those were good behind the scenes information, got to see what parts of hardware development are more troublesome than others.
The Navspark board
The rewards just shipped this week, and since for this campaign I’m a “local”, I got it pretty early. I got my Navspark GPS/Beidou (BD) version in a big envelope, together with an antenna, some pin and a jumper.
Ever since someone donated an IP phone to the Taipei Hackerspace, I’m trying to find time to set up an internal phone network between the hackerspace members. It should be fun to make our own infrastructure. Recently did some research, and started with it. Since if I get into something then I dive deep for a while, this was an intense week. This post is to summarize where I have got in this time
Asterisk & FreePBX
A bit of searching turned up Asterisk, a PBX (“private branch exchange” aka telephone network) software. It looked interesting because it came with a story: a guy building something awesome because he doesn’t know that it was supposed to be difficult. It’s also open source from the start, with a successful company build on top of the project.
Also found, that there’s a graphical control panel called FreePBX that makes using the all-command-line-and-config-files Asterisk easier to use. Both projects had a seemingly very detailed wiki, long track record, and strong following that made it worth checking them out.
Judging from the original install instructions on the FreePBX wiki, it looked like installing Asterisk & FreePBX is a complex (or rather many-step) process. Didn’t want to litter my own computer with broken installation artefacts, so enter VirtualBox. Using a virtual machine makes it easy to wipe and restart.
There’s a dedicated, preinstalled FreePBX distro based on CentOS, but had enough of CentOS for a while. Instead I just took Ubuntu 12.04.3 as a base, and FreePBX 2.11 and Asterisk 11 from the wiki. The install instructions were clear enough, though occasionally there were small differences needing a fix. Nothing major, but had to play around. After 5-6 reinstalls with increasing experience I got the basic functionality working, calls placed between and such, but the performance and sound quality wasn’t really that good. After thinking what could I improve, decided to take the next step: get out of the virtual machine, and up the version numbers (I’m Arch Linux user with a reason, living on the bleeding edge).
Enter DigitalOcean, a hosting provider that I used for other projects before (cheap, fast with SSD, good service). Set up a machine (aka “droplet”) in their Singaporean center (since that’s probably the closest one to Taiwan). I chose the 1Gb memory instance, because from experience with VirtualBox Asterisk+FreePBX maxed out at around that with a few test accounts.
Upping the version numbers I went with FreePBX 12.0 (from git) and Asterisk 12.1.1 (from download), both are testing versions. Asterisk had an extra dependency of libjansson-dev compared to version 11, didn’t check if any of the earlier dependencies are not required anymore.
Got the whole system working (after a few droplet wipes), and played with the installation with a bit more confidence. From initial experience, Asterisk is a bit like the Linux Kernel. It’s modular, complex, focus on reliability, and the “make menuselect” is a familiar environment after years of “make menuconfig” compiling my own kernel. On the other hand, FreePBX is a bit like WordPress. It has its own auto-updater (just like updating plugins in WordPress), loads and loads of menus, focuses on configuration and tries not to let any faulty module take down the system (found quite a few buggy behaviour, so that’s a good idea). The Kernel and WordPress are two familiar environments, so felt home here too somehow.
Asterisk has a bunch of vocabulary that I’m so far barely familiar with, and lots of functionality that I haven’t had a chance to test yet. FreePBX has a lot of functionality too, and still it’s a bit difficult for me to tell where does an Asterisk function (module, resource?) end and one FreePBX function (plugin?) start. The fact is that I got to feel excited about programmable phone routing (with Lua), fax-to-pdf, hotel style wake-up calls, voicemail recording, call tracing, speaking time, simple conference talks, intercom functionality, regardless from whether it’s a module or a plugin…
Some additional server notes: voicemail requires email out for notification, I set that up with Mandrill and postfix. For such testing it might not be important, but good to secure the server at least a bit with fail2ban and ufw (Uncomplicated Firewall), and probably other things I don’t do well yet. Just sayin’.
Accounts / Extensions
Accounts on the server are the extensions on which someone (or something), a numerical value. The vocabulary and concepts are also new to me, so it took a while to understand how things supposed to interoperate. Asterisk has a bunch of different kinds of extensions, of which I have tried two main ones: SIP and IAX.
SIP stands for Session Initiation Protocol. As far as I see it is basically a messaging protocol, to set up a connection between two parties, and also provide some other services, for example presence information (Online, Away, Busy….), messaging, and what not. The actual data of the call (voice or video) is trhough RTP (Real-time Transport Protocol).
The voice data in the transmission is compressed with one of the many codecs available:
ulaw and alaw (G.711) are a pair of the standard codecs, okay quality, one of the basic one to have in any client
speex is a variable bitrate codec, haven’t used that much
gsm is lower bitrate, but lower quality too (think of crappy cell phone reception voice)
G.722 is a hi-def (HD) voice codec, really good! I think beats Skype, and on par with a good Google Hangout quality,
G.729 is a non-free codec, shows up here and there, but haven’t had a chance to try it, this is the other HD codec that I’ve seen recommended
In testing, this was some of the learning curve, how to set up clients, and also the server that they can communicate with each other. Who choses the codec (caller, callee, server)? How to prioritize the codecs in different clients? What does it look like (or sounds like) when there’s a problem in this area? How to debug and fix?
Asterisk 12 has two different SIP channels or components: their classic library (chan_sip), and a rewritten one (chan_pjsip). The latter one is a standalone library that can be used for other purposes as well. SIP usually works on UDP, while PJSIP can do UDP/TCP/WebSockets too, and feels stable and fast. Definitely would use that if I have to choose between these two. Still, it is in test phase (both in Asterisk and FreePBX), so not without headaches.
There are bunch of different clients that I tried:
Ekiga is nice, simple, can sign into multiple accounts in multiple networks. Presence information, well integrated into the desktop with notifications and such. Does not seem to be able to handle non-standard SIP ports (which will be an issue further down)
Linphone is really multiplatform (Linux, Win, OSX, smartphones…), but it was crashing on me quite a bit, doesn’t integrate into the desktop (no notification just sound on call), and can be confusing with the lot of settings (the control panel looks a mess). Can handle non-standard ports too.
SFLPhone is good, works pretty well, simple, and can do IAX communication besides SIP.
Android actually has full SIP handling capabilities built in for a while now (under “internet phone”). That would be awesome, if there were more information how to set up and use, but in theory a SIP account can be fully integrated into the system.
CSIPSimple really impressed me, probably the best working client I found. Integrates with the system (calls are handled as ‘calls’ with all the icons, history, and so on), good sound quality (can use the G.722 codec) and so on.
SipDroid, VIMPhone, LinPhone…. these other clients, don’t even remember them, all of them fell short somehow
Zoiper stands out as well, not just because it’s multiplatform, but because it’s pretty much the only one I found that can do both SIP and IAX. The Android system integration is not as close as CSIPSimple, but quite okay.
One of (the many) good thing about SIP that it is well known and pretty well supported. If there’s a “softphone” (phone in software), it’s quite likely to have SIP communication capabilities.
The bad thing about SIP though that it is well known and pretty well resented by the phone service providers. Many of those providers block SIP messages on their network, or sabotage the connection in some other way. On my own cell phone / 3G provider’s network, I couldn’t connect to Asterisk. In the forums some suggested that changing the port number that Asterisk listens on for SIP connections can solve things – and indeed after moving away from 5060/5061 to somewhere else, I could connect. The celebration was short lived, though because even though the calls now can reach the destination, RTP communication (the part that actually transports voice) was still broken. I don’t want to use VPN all the time (though might need to soon), and want to keep moving parts and settings to the minimum if I want others in the Hackerspace to join this network as well, thus SIP looks like a no-go because of the phone companies (darn).
Looking around, I found another type of channel, using the IAX (Inter-Asterisk eXchange) protocol. The bad thing about it that it is much less supported, but in turn it is not blocked by the phone companies either (since they don’t know about it).
Using SFLPhone and Zoiper I could successfully talk over 3G! Still it is not all good, the devil is in the details.
It’s good that no need for custom ports
It’s bad that the IAX channel seems to be more unstable on Asterisk (or maybe I messed up my install after a while?): some extensions have trouble logging on for a while until the server is restarted; the wakeup-calls plugin misbehaved with IAX extension.
The less support also means less choice in clients. The ones I found cannot do G.722 so no HD voice anymore
Has a security setting (requirecalltoken) that not all clients support, not sure if there are any implications.
It’s also good, that Asterisk can route incoming SIP calls onto IAX extensions (i.e. the caller doesn’t have to care what technology the callee is using). On the note of routing, I could set things up such that outside calls can be routed into the system. E.g. every hackerspace could have their own Asterisk server and interoperate to call members at other spaces – sounds like a lot of work and might not worth it, but it also sounds awesome.
Summary & Future
I had a lot of fun playing with Asterisk. On the surface phone networks are familiar to everyone, but going deeper both makes things more confusing and opens my eyes how many possibilities there are for making something useful.
There are a lot of things that I thought about, but haven’t tried yet:
Programmable dialplans (“what happens when a call is received”), via Lua. Lua is an awesome language and probably a lot more large piece of software has it embedded (since that’s one of its strength)
There are a bunch of other protocols and acronyms in Asterisk, for example Secure Real-Time Protocol (SRTP) and ZRTP, that could worth figuring out for a deeper understanding and security
There’s an Asterisk on Raspberry Pi project that looks interesting (if nothing else then how do they lower the memory usage below the RPi’s <512MB?). Since Asterisk can be used with multiple servers in a network, the RPi can provide one kind of service (e.g. GSM gateway) while other servers with more resources do other stuff
Using physical phones in the network, for example traditional phone network to come into the server, and IP Phone to ring out. Maybe setting up fax endpoint (and sending it out as PDF or printing it). Basically anything that is working on the threshold between physical and digital.
Should check out how the likes of Line, Voxer, and Viber are doing VoIP on Android, do they have any interoperability?
How about Twillio, can their system be a similar PBX on a much larger scale?
The funny thing is that looks like the original IP phone that started this whole adventure does not work with Asterisk. Never mind, it will be good for another project.
A recent simple battery change operation of a small multimeter (DT-182 or a clone of thereo) turned into a disassembly, when I heard a little rattling noise when shaken after I put in the new battery. I was curious if there was anything loose inside the box. Took some pictures of the inside of the multimeter, and added some notes to how things seem to work. I try to guess the origin of the design choices within hardware, in a way to learn a bit about hardware manufacturing.
The first thing I did is unscrew the PCB and see whether anything is between that and the front of the housing.
The things I noted here: the knob, the screw hole placement, and the LCD-PCB interface.
Now I understand a bit better how the knob works: the little metal brushes make contacts differently for different position of the knob, and the control electronics knows the required functionality based on reading those connections (specific shorts? specific resistances? that I forgot to check). The brushes are weird a bit too: one fell off and I tried to put pack but didn’t see how it could be attached. Turns out, that the slit in the middle is a bit narrower than a plastic edge underneath, and the brush sticks on to that (barely). When pressing agains the board, the triangle shape can flatten, and keep physical contact. There’s also a whole for the knob centre that is not screwed, but keeps the knob from wandering
The screw hole placement for the PCB is in a triangle shape around he knob. I think it’s a good way to keep things tight with the smallest number of screws.
The LCD interfacing is pretty weird. The display segments of the LCD are controlled through the big bunch of lines on the top of the board. That is touching a rubbery contact stack on the top of the LCD. I guess it’s rubbery because it needs to be able to compress easily. I wonder what’s the conductive material within that . There’s also a plastic bar that the PCB pushes down and which in turn pushes the display down, i.e. into its place of the exposure. I think it’s a quite cool way for easy assembly but holding things quite securely in place. The PCB slips into some slot on the top the enclosure, and pushed into place on the bottom (the metal tubes go into the plastic holes, and the electrodes into their respective slits).
Taking the knob off, it’s held in place by the balance of the PCB pushing down on its back, and a pair of ball bearings. There’s a spring under each of the bearings, which is within a plastic hole, while the ball is a bit larger than the whole, so it cannot be stuck inside of it. The positions of the knob are set by the holes in the plastic ring (on the left of the image. The balls are greased somewhat, quite sticky. Putting things back together was a bit tricky, not letting the balls fall out on one side, and the brushes to fall off on the other.
The PCB is secured to the front assembly with three screws. One of them also holds a buzzer in place and that screw is a bit longer – thus not all screws are the same in this gadget.
The backplane has a pair little grooves on the top which fit into the two hinges on the top of the frontplane (I really wonder what’s the proper name for those parts…). Other than that, two screws on the bottom secure the back. The battery is held in place with two plastic legs (between the screws of the backplane).
After the second try, I could put everything back and the multimeter seems to work.
Funny thing, when I shake it I can still hear the rattling noise. Now that I’ve seen the inside, looks like it’s the plastic piece that should help to hold the LCD down, so probably it’s smaller than in the other multimeters like this we have, or the PCB is not fastened as much as it is supposed to. Though I don’t like over-fastening metal screws in plastic threads – recipe for shredded threads.