Hi, this is Wayne again with a topic “Interview with Julian Saunderson”.
Hi, i’m julian sanderson i’ve been developing for small devices at church, the software that’s on phones can receive chirps and do some clever decoding and can also play chips. Of course, the challenge that we’ve faced is first getting small devices to play. The chirps we haven’t tackled. The decoding side yet play the sounds.
They have to generate the waveforms in real time, and that is a little bit of a challenge for very low power devices such as arduinos we’ve used some very tight timer driven code in a system. That’S very much like pwm. In which, if you were familiar with that, that’s pulse width modulation, that means that, in order to create a varying waveform, you change the proportion of time slots that keep the pins on.
So if you want to be at the top of the waveform, you would keep a pin turned on for the whole length of your little time slot, and these time slots are very short, we’re talking about 62.5 000 of them a second. If he wants to be at the bottom of the waveform, you keep that time slot, where you keep the pin low for that time, slot and anywhere in between you keep the time that it’s on proportion, so what’s happening, is that 62.5 000 times a second we’re Changing a setting for a timer to keep a pin, turned on and we’re doing a little bit of calculation to work out where we are in the codes for the tones so that we can play the waveform one side of what we’re introducing today is the playing Side of things, the synthesis that was one challenge, the other side of things – was that the usual chirp server is much too complex for a small device. The moment we’re handling the whole http exchange within a single buffer of 800 bytes, or so so we had to keep the exchange. Very small and chirp have introduced a very simplified api on their hummingbird server, especially for devices such as this and such as the arduino. If you have chirp codes ready prepared, you can play them straight on the board and that’s fine, and that would be a great way to pre-prepare little fixed messages that you can chirp out from your device and it can be picked up by anybody with a mobile Phone running the for each other, if you want to create new chirps, you need to inform their database server of those and that’s what you need the api for, so you can create from small devices. At the moment, you can create chirps that hold a text message or that’s very usefully linked to the web.
We started looking at a very small end device which had about two and a half k of ram and about 30k of programmed space, and that’s fine for what i’ve been talking about so far running the api and playing chirps as we progressed with chipino. We added more and more features to it and we now have an all singing all dancing means of exploring world of chirps and we’ve, given it so many commands that it probably won’t now fit in to the original device. But we’ve moved on to things like the arduino mega and to the spark core that i have in my hand. Here they manage four playlists of ten chirps by default.
That’S stored permanently either in the eprom in the arduino or in flash memory in the spark you can schedule playlists to play at different times, so you can use it as a demo unit. You can attach them to buttons or other triggers and on the spark core, of course, because it’s connected via the cloud to the spark system you can send cloud-based commands. So you could make a little web interface to trigger your chipino device. We are making the api to the web interface and the library for chirping available to the smaller devices, though as well.
Moving from the arduino to the spark was interesting because it was the first time i’ve programmed arm chips directly and there was some need to get hold of the timer code for those as well, which is in a somewhat more complex world than the arduino. So we’ve kept things simple in this instance and we just basically run the synthesis code, all in one loop, which turns off, interrupts and just gets on with it itself at some stage. I might revise that because we have the power of the 72 megahertz here to do it in a more open way. It’S a very impressive device, but spark photon coming very shortly, is looking to be more impressive, still and we’re looking forward to moving the system onto that.
I think it will be quite easy to port these systems onto other devices, because the only really technical bit that was very closely assigned to the device is the timer code for the synthesis. And if somebody in the community can manage that, then your flying, the rest of it will will just come with it. There’S some specificity to the storage methods so that you use eprom on the arduino just one style. I’Ve created a little degree of abstraction for that.
So that the spark system which writes to flash actually uses very similar code for most what it does so the porting shouldn’t be too hard. I think it’s a great way for very small devices to communicate to people it’s a charming way to send a message out. It requires very little hardware: we’ve had a lot of success with just directly wiring and earbuds to the pins of these devices, and we’ve also had successes just wiring up an audio jack and plugging that into things like an old radio. I think in both these cases we are at going beyond the bounds of the expected signals, so use at your own risk. You certainly wouldn’t want to put earbud in your ear when it’s playing, but it’s a very quick and cheap way of getting something that can communicate attached to your device. So if you’ve got a sensor-based system or even something that’s doing, demos for sales, you can communicate with people very easily. You .