As someone who enjoys (or drawn to, or sort-of obscessed with) hacking on hardware, this was a nice call of action: let’s cobble together a custom USB button that can do some kind of call control¹: say muting myself in the call, showing mute status, hanging up, etc.

This kicked off such a deep rabbit hole that I barely made it back up to the top, but one that seeded a crazy amount of future opportunities.

And as a shortcut, there’s a demo below to showcase where I got to.

Finding suitable hardware

This step was harder than I’ve expected, given that I have drawers and drawers of gadgets, but I’m likely a bit out of practice, and also out of date. What I was looking for is

• Being able to show up as a USB device (must)
• Have built in button (optional) or easy connectivity of buttons without breadboard for now
• Have built in LED (optional) or some other way of showing 1 bit of information

This doesn’t sound hard, right?

ReSpeaker

The first option that came up was Seeed Studio’s ReSpeaker Core that I had two of at hand: Arduino Leonardo compatibility, touch sensors for buttons, and an LED ring (the “Pixel Ring”). Turns out that they have been discontinued – which should be fine for now; but also my models are two different pre-release prototypes Seeed gave away for testers. Thus they are not quite like the final version, have different hardware on board here and there, so an experimental experience is expected.

The earlier prototype only has touch sensors on one side, the pixel ring lights up, but I couldn’t control it with Seeed’s ReSpeaker Arduino library. The later prototype has two sides of sensors (effectively two buttons), but the lights don’t seem to work². Regardless this

Aside: alternatives considered

It was illuminating to see how much abandoned, obsolete, discontinued, or not quite useful hardware boards do I have.

One is RFDuino, that I got from Kickstarter, I’m yet to use, and all the project’s websites have already disappeared – fortunately not the code repo. This would have been a more complex solution anyways, but wireless! Use one RFDuino to expose a USB Telephony device, and communicate wirelessly to another that operates the light and button on battery. Pretty cool. Also, it might not have worked if the chip used cannot do the cruicial “expose a USB [device]” part of the plan.

Other option that popped up was an Arduino Nano + my own made GroveHat + a Grove Button. Except, the Nano definitely cannot be a custom USB device, so there goes nothing.

Besides these, I’ve found plenty of:

• single board computers (old or obsolete),
• FPGAs (never used, and would be a whole different project to implement something on them), and
• other microcontrollers that all have interesting specialties, but don’t tick the mandatory boxes…

These boards might not be right for now, but definitely there are projects in store for them (if only thre’s time).

Back to ReSpeaker then…

Plugging in the USB

The next thing is to figure out what’s really happening when an USB device is plugged in and it shows the operating system that it can do certain things. That is, how does Meet know that there’s a compatible device to connect to?

The USB HID docs

This is answered by the USB Human Interface Devices (HID) specs — one that is pretty complicated, has a lot of legacy bits, and need a different kind of mindset. In a nutshell, though, with my current, partial understanding:

On connection the device sends a “report” to the OS that details on what can it do, including:

• what kind (or kinds!) of device it is?
• what functionality of the kind is available in this particular implementation?
• what’s the data layout to pass control information back-and-forth for this implementation?

In our example, a very minimal setup would would be:

• I’m a Telephony Device (Usage page 0x0B)
• I implement a generic “Phone” (Usage ID 0x01)
• I have capability to do a “Phone Mute” (Usage ID 0x2F)
• Here’s the 1 bit of a 1 byte payload that conveys that phone mute status

This course does not take into account other functionality, e.g.

• I can also hang up – Hook Switch, Usage ID 0x20;
• I have status LEDs – that’s a whole fun of redefining functions on the LED Page 0x08;

and so on. But for the time being this should be enough.

Device implementation

Fortunately we can stand on the shoulders of giants, that is the Arduino HID Project which implemented a bunch of different devices. And even though a “phone” like this is not among them, we can make some reasonable guesses how it would work.

Having said that, from a forum post that was also trying to do something similar (but based on the TinyUSB library):

HID report descriptor is very difficult thing to come up by oneself. You should google around, or dump report descriptor from existing device to copy/follow it.

hathach @ TinyUSB discussion 667

Okay, then do not come up with this stuff, instead let’s look for tools. The USB HID homepage links to the Microsoft HID Tools to generate HID reports from a TOML-like language. Except it needs C# and I just wasn’t ready to dive in a side-quest to install & learn a new toolchain.

So being lazy this way, a bit more sleuthing turned up someone’s example HID report for a device very close to what I’m trying to do, hurray!

I took this and started to poke around the HID project to see how other devices are implemented. Troubleshooting by using the ReSpeaker’s touch to adjust screen brightness up / down (as a “Consumer Device”) was also pretty neat! In the end I took the system buttons example and run with that one.

Having said that, the HID report is really just the interface. The devil is in how to implement actually creating the data packages that passes data according to the report definition. And this is the case when I wish I knew more C++ but copy-paste and some guesswork will have to do.

The current result lives in the “phone” branch of my HID Project fork, check for the “Phone” bits in “src/HID-APIs” and “MultiReport” folders, if interested.

Minimal viable mute

The implementation from this point on was pretty straightforward – since we cut back the scope so much…

The code to run on the ReSpeaker then just has to do the following:

• when touching one side, send a report with “Phone Mute” on
• when touching the other, send a report with “Phone Mute” off

And this is sort of simple³ :

For the full use case there would be a lot more complexity for both reading and writing data from the host, controlling multiple peripherals (LEDs and buttons) and the whole logic around it. But for now, it’s good enough for a demo:

The code repository is available on Github at imrehg/arduino-usb-phone-hid.

Notes and Future work

The specs

It’s great that stuff from 20+ years ago still works mostly the same way. The latest 1.4 version of the HID Tables is nicely formatted, has a lot more device typed defined, but has much less support text. Originally I’ve read the 1.12v2 version as that showed up in my search. Back then in 2004 they had an “examples” section (see the Telephone at Appendix 10!) which is useful to grok more of the fundamentals.

The newer version also has some devices types that looked suitable, but weren’t really: Generic Desktop Page (0x01) and 0xE0-E2 Usage IDs for Call Active LED, Call Mute Toggle, and Call Mute LED respectively. These didn’t seem to work with Meet, so it might be interesting to try implementing a device that does both and try other online call software.

I should also have read the spec more before diving into hacking on the HID implementation fork, as there’s a lot more information in the HID Device Class Definition, including how to construct the values for many of the fields (I’m looking at you “INPUT (Cnst,Var,Abs)“). RTFM is and remains a solid advice – and not just when one thinks there’s time.

Also regarding the specs: some of them I only find in the Internet Archive’s Wayback Machine. If you encounter a good source that should be kept, always add it to the Wayback Machine and preserve it for your future selves and others!

This exploration of USB HID pulled on so many threads, and left so much unfinished, that it’s a fertile ground for the future, even more than most previous projects.

More call functionality

The most obvious thing is to implement the whole setup with the buttons. I’ve tried Hook Switch to hang up a call, that works too. Could add status lights, maybe throw in some “Active Call” LEDs, or so on. This requires better understanding how data is sent over the wire for USB and how to handle incoming data. The Arduino examples rarely seem to use the “Output” fields (ie. incoming data, output from the host’s point of view, but maybe TinyUSB does ?

For this, it would be nice to find a different hardware platform that would make this more seamless (so I can concentrate on the software side more). If that platform would lend itself to be reproduced or made stand alone, that would be even nicer: imaging brining my little call control box that can be used with other computers easily as well…

Implement more USB HID devices

The Arduino HID project has a bunch of devices implemented, but there are an infinite numbers that could be added. Unfortunately for Arduino it is harder to add more device types as an add-on to this library versus the current “forked” approach⁴, so new decices should be in the main project, eventually.

So far there’s no Telephony device implemented there and it would be nice to find the right level of abstraction that works. The library doesn’t implement specific HID table pages, but specific usages or a subset of a usage. Thus like always, the hardest part would likely be setting the right interface (the right specs and “API”) for a new device to implement both the HID reports and the functions that manipulate what’s being sent and when.

On the other hand, that does sound like a fun experiment, and I’d look forward to adding 3D Game Controllers (Game Controls Page 0x05), Environmental Sensors (Sensors Page 0x20, Usage ID 0x30-3B), … or even a Submarine Simulation Device (Simulation Device page 0x02, usage id 0x05). These are stuff I go to Hackerspaces for…

WebHID for internet plus USB

While debugging this HID device behaviour, I found also WebHID that brings such devices to the web. This feature seems to be behind Meet’s and other phone systems like 3CX expanding USB support outside of the OS and into the browser. And no, Firefox does not support it, furthermore declined supporting it.

Nonetheless it’s very cool that (if I upskill a bit), I can create a web page that would help me debug such HID development:

• request devices that are filtered in various ways (vendor, product is standard, but usage page and explicit usage is the main key). This is likely what Meet does as well, “just gimme devices with Telephony usage page (or Phone usage? Need to check exactly)
• read the HID report collections sent by the device, so the results can be debugged, and
• read device input events that we can then either log for debugging or in an application react to to it

This opens a lot more mashup opportunities by the dozen.

Finally

Unlike most other projects I had where I’m focused on one specific outcome, this turned out to be more focusing on getting a new toolkit (custom USB devices) up and running, so I can think about a wider types of projects to do. In that sense, this feels a big success, even if I know how little I know about programming outside of my day-to-day environment. But ignorance is not a bliss.

And now, going on mute.

1. Many moons past I used to use a Jabra Evolve 80, that has a USB accessory controlling call features, so I did have first hand example of what sort of experience I’d like. ︎
2. I’ve tried reviewing the hardware schematics, looking into the pixel ring control functions, and given that the LEDs seems standard I’ve also attempted to use the FastLED library to drive them instead, so far nothing. I still bet on hardware differences from final schematic + my inability to debug it, but it can be faulty hardware just as well. Needs more effort – in the future. ︎
3. The Arduino code became more “simple” once I realised that things set up this way do not need debouncing for the touch sensors. In other cases that would be essential, there’s sooo much flaky signal to use those terminals as momentary switches or similar. ︎
4. At least I don’t know how nicely extend a library for C++, if that’s even possible. Keen to learn, though. ︎

The post Making a USB Mute Button for Online Meetings appeared first on ClickedyClick.

The target solution: light up an LED if a particular person is at home location. Sort of a basic alarm system, though notice that the location of the LED was not mentioned – it can actually be anywhere in the world, as long as there’s Internet connectivity.

I’ve used the Wio Link, a Grove LED light, an Olimex OLinuXino Lime2 board running ArchLinux for the server, and a Buffalo router with DD-WRT system installed.

Wio Link

Wio Link was introduced in Seeed’s Kickstarter campaign, where they have raised more than 8x of their original target. It looks like a neat little board, and was happy to try out when I got my hands on one.

Their wiki page has quite a bit of information, so it was easy to get started. Connect to power, hold down the configure button till the LED lights up in a “breathing” pattern, connect through their Wio Link app, set up the wireless network settings and so on. Once connected, can define what kind of devices are attached to the board, and it looks like most of Grove devices are represented there. I only had a Grove LED at hand, so added it (“Generic Digital Output”), updated it, which created a new firmware and pushed onto the device.

The first update took a couple of minutes, but it’s pretty straightforward. The device then also has an API link, which brings up a web page with all the options to query, control, and reset the attached accessories (in my case that’s the one digital output).

The API is pretty simple and usable, though definitely not perfect (will come back to this).

Since manual switching the light on and off worked like the charm, the next step was to enable automatic switching by the presence detection within the home automation system.

Home Assistant

Home Assistant is an open source home automation system written in Python. There’s a lot to like about it, and a lot of people are checking it out since a number of other, closed system providers are shutting down their services. On the other hand, figuring out the configuration to implement the automation steps I came up with is far from trivial…

Setting up Home Assistant is pretty simple. Create a new directory, add a new virtualenv environment, and install home assistant (I’ve added some bonus modules that the logs recommended):

$ virtualenv env
Using base prefix '/usr'
New python executable in /tmp/env/bin/python3
Also creating executable in /tmp/env/bin/python
Installing setuptools, pip, wheel...done.
$ source env/bin/activate
(env) $ pip install homeassistant
...
(env) $ pip install python-Levenshtein
(env) $ pip install colorlog
(env) $ hass --open-ui

Next step is adding the actual components (the pieces of the home automation).  I’ve implemented the Wio Link light as a Command Line Switch. It has two commands for “on” and “off”, plus an extra for checking the on/off status (this latter is a very nice touch, and works well checking whether the switch took effect). In the configuration.yaml  file in the ~/.homeassistant  directory:

switch:
  platform: command_line
  switches:
    presence_light:
      name: Home Presence Light
      oncmd: "/usr/bin/curl -s -X POST https://iot.seeed.cc/v1/node/GenericDOutD0/onoff/1?access_token=<token>"
      offcmd: "/usr/bin/curl -s -X POST https://iot.seeed.cc/v1/node/GenericDOutD0/onoff/0?access_token=<token>"
      statecmd: "/usr/bin/curl -s https://iot.seeed.cc/v1/node/GenericDOutD0/onoff_status?access_token=<token>"
      value_template: '{{ value_json.onoff == 1 }}'

group:
  remote:
    - switch.home_presence_light

Here the URLs are coming straight from Wio Link API page, and you have to add your token value and the correct channels instead of GenericDOutD0  if you plugged your light into a different connector than me. I’ve also removed their -k  command line parameter (allow insecure SSL connection), and added  -s  (silent mode). The last section starting with “group” is not really necessary, but could group devices to be controlled together.

Adding the presence detection through DD-WRT is just the same as in their example configuration, obviously add your own parameters.

device_tracker:
  platform: ddwrt
  host: 192.168.x.y
  username: <user>
  password: <password>
  interval: 10

I don’t like that username/password is in clear text, so better protect your Home Assistant device and this configuration file!

By the default configuration, after restarting Home Assistant this presence detection module will create a known_devices.yaml  file in the ~/.homeassistant/  directory and add all new devices (see the device tracker component page for some more info). Here I had my smartphone, after connecting it to the home network.

xxxxxxxxxxxx:
  name: HTC One M9
  mac: xx:xx:xx:xx:xx:xx
  picture: http://www.gravatar.com/avatar/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  track: yes
  hide_if_away: no

That file then can be edited, for example  adding device name, disabling tracking for some discovered devices (eg. the small server running the Home Assistant server itself), and adding an image. I’ve added an image using a Gravatar link, where the xxxx section is just the md5 hash of your email, get it by.

echo -n "my@email.com" | md5sum -

Alternatively, this week’s update added local file support too, as it was discussed in the Home Assistant blog, so files in the ~/.homeassistant/www/  can be linked through the http://127.0.0.1/local/  path, so no online link is necessary (but I think Gravatar is a good unified approach).

After all this, the control interface will look something like this (the Sun is added as I had my home’s longitude/latitude information in the configuration). My icon will show Home/Away status, and clicking the switch on the presence light will trigger the light on the Wio Link.

The final step is the automation. This was the hardest step, as the Home Assistant automation documentation and their cookbook is pretty shallow, and often feel confusing. In the end, one working result is this pair of rules, which turn the light on when status change to home , and turn it off when changes to not_home  for that particular device.

automation 1:
  trigger:
    platform: state
    entity_id: device_tracker.xxxxxxxxxxxx
    to: 'home'
  action:
    service: homeassistant.turn_on
    entity_id: group.remote

automation 2:
  trigger:
    platform: state
    entity_id: device_tracker.xxxxxxxxxxxx
    to: 'not_home'
  action:
    service: homeassistant.turn_off
    entity_id: group.remote

I’m sure it can be done differently, but I’m also just glad it works, as it took quite a few hours of checking documentation, trying things, and reading the Home Assistant source code to come up with a working solution.

It functions pretty well, though presence (arriving) is detected quicker than absence (going away), I guess that’s part of detection method and certain timeouts within DD-WRT.

Lessons

I quite like how it all turned out, and I’ve learned a lot along the way, in the about 5-6 hours it took to pull everything together for the first time.

There will always be bugs. When trying to read the Wio Link LED’s status, first I was trying to implement it as a RESTful Binary Sensor. Took a while to find that that component had a breaking bug. I’ve made a patch, but haven’t sent it upstream yet, because Home Assistant makes me fill out so much information before a pull request can be even considered. To make it worthwhile, I’ll review things and send the fix later.

Not all the Wio Link API design is great. In particular, turning the light on/off are empty POST request to two different API endpoints! That’s not really REST at all. I think the way it should have been is using the same API endpoint (one single URL), and the setting sent over the POST data. Because of peculiarity, I couldn’t implement the Wio Link control over the RESTful Switch component, which requires a single endpoint.

Since the Wio Link can be placed anywhere where there’s internet connection, this home automation system can incorporate data from anywhere, sending or receiving. Can have an LCD screen miles away that displays metrics from your home. Can incorporate external sensors, actuators, the whole shebang. This makes more of a “local area” or even “wide area” automation network, not just “home”. Let your imagination run amok!

The Home Assistant documentation is really lacking for me, and I say that while every component has code samples and there are a lot of cookbook samples around. The problem is that there’s very little consistency, there’s no overview, and the options are not documented extensively. There’s no list of “these are all the options and possible values”, and there are no “these are all the ways you can do this thing”. In the end, one needs a lot of trial and error and monumental amount of head scratching! (Use the Source, Luke!) All this basically means that Home Assistant is the “worst documented project that I’m the most excited about“. :) Fortunately the Home Assistant website’s source is also on Github and can submit updates if I figure out how to explain things better.

Creating automation through triggers, conditions, and actions is probably pretty straightforward at first. I guess it works very well for simple systems, though I wonder how it could be made to scale better. In this configuration based system, even just a couple of automation scripts can balloon to pages and pages of code, and possible very little operator understanding how rules possible cross-interact with each other. I don’t know what model would be better (some kind of state machine definition maybe?), but it would worth thinking about it for the long term of home automation.

There are more components defined than I could reasonably ever try in my life, just check the component’s page!

This abundance also means that the number of possible combinations are astronomical. I would wager, though, that the value of those combinations follow a power-low: most of the combinations are not interesting at all, while a relatively small number of combinations are the most useful in general! I guess the Cookbook would be a good place to highlight some more “common use cases”, not just covering the bases and filling in for the lack of documentation. There are some obviously more useful components, IFTTT component on its own can add a ton of functionality, or the RESTful components.

Future

I hope, that more device manufacturers will create components and generously add it to this lineup. I can’t see any downside and there’s just so much upside working with an open source system! Any system integrator that figures out Home Assistant will also have a big competitive advantage in some niches for sure.

I hope, that the documentation can be improved in the future and things will be easier to figure out (e.g. how would I update this project above to light up the LED if any one of the tracked devices is present and turn the LED off when all of them are absent?).

The huge number of possible component combinations to mix-and-match is also pretty paralyzing too (see the classic Paradox of Choice), I have no good “production-level” project in mind yet, even though I’m super excited about many components I’ve found so far! This particular project worked, because it’s already something I was thinking about, and could possibly replace an existing system in the Taipei Hackerspace!

Have you built something interesting? Would love to hear about it! :)

The post Home Automation Mix-and-Match appeared first on ClickedyClick.

The Experimental Extensions define a smallish API, which can be used to create custom programming blocks to be used in Scratch. All it needs is a Javascript file (currently) hosted on Github with a few pre-defined code blocks to unlock any sort of functionality. This creates a possibility to easily tap into any kind of web API or interface any hardware that can be addressed somehow through Javascript. There are a large number of examples already, and I wanted to see how easy or hard it is to create such an extension for a robot that happened to be around here at VIA.

The Robot

Some of the engineers at VIA have built a small robot using bits and pieces found in the lab: a dual-core ARM-based engineering sample control board, smart battery from another project, some wheels from a commercial robot (Rovio’s 3-wheel system a few years back), and I think some office supplies.

The robot’s operating system creates an access point (with the Wi-Fi USB stick on the upper right of the picture), and hosts a webpage that can be used to control the movements (back/forth/left/right), as well as streaming video (or more precisely Motion JPEG) from the camera in the front (lower left, the little black square on top of the white sticky pad). Besides the control board, there’s some voltage converter and battery-control circuits, off-the-shelf pieces by the look of them, with minor modifications (such as an LED to see when the battery is out of power).

It is as hacky as it gets, but all that is needed to have some fun.

Controlling Through Scratch

While the built in webpage to control the robot is very handy, and can be used from any device that has a browser (computer, smartphone, I guess could even control it from a Kindle), it has it’s limitation: I need to click on buttons to get things done, and nothing can be really automated. Still, the underlying API is a good start to do more interesting things.

The API is very hacky too, and that’s just fine like that. Looking at the built in webpage, I could see that there are a handful of GET requests to a specific URL to move_forward , or turn_left  or stop . That’s straightforward enough, and it does not take more than a couple of minutes to cook up a proof of concept Python script using requests to try these endpoints.

Once that worked, I followed the Scratch Extension documentation and some of the examples linked from the site to creating a Javascript module to implement these movement commands.

It didn’t take too many iterations to add the blocks like “move forward for X seconds” and so on for the other movements. I’ve created a basic project to show how these work, where the robot moves following the directional arrows: forward/backward, and turning with left/right. Figured out that 0.5 turning is about 45°, so the arrow in the screen can sort of follow the direction of the robot in the physical world. For good measure I’ve also added a complex block of “samba” steps (I’m sorry, haven’t been doing samba for years, but that’s what it reminds me of), which is triggered by pressing “s” on the keyboard. Here’s a demo of the robot controlled through Scratch:

The source code naturally is available on Github, both the module and an example Scratch project.

Lessons Learned

Provided that you have a bit of Javascript knowledge, it’s super easy to create new scratch extensions. The platform is very quite well thought out and flexible. That code can be so easily included from public sources is very handy. They also make jQuery available from within the scripts so that helps with simplifying code generally (especially working with web APIs).

The experience also showed me how important is the firmware in the case of hardware control. For example the current firmware on the robot never thought of their API being called outside of the browser, thus I’ve run into “Access-Control-Allow-Origin” issues. It doesn’t make things unworkable, but something that needs to be worked around. There are other robots that have extensions available, as well as an extension to control Arduino: that’s also available only because of a specific firmware, Firmata to create a proper API for controlling the boards.

Since the Javascript modules need to be committed to git, pushed to Github, and the Scratch page reloaded, it helps a lot to run the module through jslint to catch at least the syntax errors (or have an IDE that can do that for you).

Future Ideas

I got enough taste of Scratch to come back for more. There are a couple of ideas that I’d like to figure out in the future, specific to this robot project and otherwise:

I’m not using some of the reserved functions of Scratch Extension modules,  the _getStatus()  function in particular, that could show whether or not the robot is connected. Should add that functionality to this robot module, though it is not yet clear to me how things should work.

Would be great to be able to bring the video stream into Scratch. I see functionality to enable the webcam on the computer, but the modules can’t control graphics as far as I can tell yet. This would enable a lot of interesting use cases. Especially if coupled with transparent overlays. I can imagine video streams from the robot as a cockpit image, or adding facial expressions to a “matchstick person” using a webcam and image processing…

Scratch is also very good with internationalization (i18n), as it has translations in dozens of languages. The current extensions cannot be translated yet, as far as I can tell, so every extension is just single language. It could be interesting, and likely demanding, to add for example gettext style translations to the extensions, one way  i18n is done in lots of projects these days.

Have you used Scratch for any of your projects? Have you made an extension for it or thinking about making one? Would love to hear your experience!

The post Scratch Your Robot Itch appeared first on ClickedyClick.

It was a long typhoon day when I started experimenting with the LinkIt one, and and as rainy days go – I’ve felt it would be great to know how far am I from home? Of course there’s a GPS in every single smartphone these days, but a dedicated device can still evoke a different feeling. So the idea for Dorothy came about.

Basic version: where are are you?

The basic idea is connect the GPS module and a Grove LCD RGB Backlight screen, and colour-code the distance from home. The LCD speaks I2C, so can directly connect it up to the I2C socket on the LinkIt One.

The colour coding follows the idea that further away people can feel “blue”, while “green” is in general a positive colour. Thus at large distances Dorothy should be more blue, while near home more green. Since the distance scales over very large values, logarithmic colouring comes handy:

• Below a minimum distance 100m be totally green, that is (0, 255, 0) in RGB
• Above a maximum distance 10,000km be all blue
• Scale between such that the blue value us floor[log10(distance in meters) – log10(100)]*51.5, and the green value is just 255 – blue.
  • For example, at 1800m the blue = 64 = floor((3.2552 – 2)*51.5),
  • then green = 191 = 255 – 64

The text is also changing by the scale: at large distances don’t have to be too precise, at short distances nicer tho show more, and at all scales use the 16×2 display as fully as possible.

The end result is something like this:

The distances are calculated using the Great Circle formulas and 6371km as the Earth’s radius. The board has of course enough computing power of course to use the more precise Vincenty formula, and the Math library has all relevant functions at hand.

It’s pretty cool that the LinkIt One comes with the LiPo battery by default, so all of this setup is super portable. Not sure how long the system works on battery, but so far my guess is “definitely more than 30 minutes”, probably at least a few times more than that.

Taking Dorothy on the is a perfect use case, here’s a video too, just for fun – so don’t mind the quality too much, no stabilizer for my camera, and this a moving train after all…

https://www.youtube.com/watch?v=c83YCSIv55I

The home location here is hard-coded into the program flashed onto the board, so to change it, one needs a computer to modify and reflash. That’s not very handy, so let’s upgrade things.

Level up: leave a marker

One way to make this more useful is having the ability of dropping a marker. Imagine that you are travelling to a new town and want to know during the day how far you are from your lodging. Drop a marker at the lodging when heading out, then later can use the distance as “breadcrumbs” going back (realistically – to augment your map, but still).

For this I needed to add some way to interact with the board – a touch button! The LinkIt One does not have any Grove digital I/O connector (just an I2C and a Serial), so had to add  Grove Base Shield into the mix too.

First I’ve tried with a Grove Button, but it seems like some pull-up resistor default setting makes it stuck at “permanently pressed” (as others reported this bug too). I guess there would be some deep software setting that would fix this, but in the meantime I went with a Grove Touch Sensor instead, as it was reported working (it does work!)

Now the logic becomes the following:

After bootup Dorothy looks for GPS satellites. When it finds some, shows the distance from the hard-coded location. Now touching the sensor will save the current location as the home.

Then of course you’ll appear instantly “at home”. The location info is stored on the internal flash, and so it will survive reboot.

If starting the board in “Mass Storage Mode” (by flipping the appropriate switch near the back of the board), then you can find the saved location data in a file called “homelocation.log“. You can also update that file to add a new home location without reflashing (the contents are just decimal longitude & latitude, both followed by a comma, and without any space or new line).

If a location is already saved, touching the sensor will clear the location data and goes back tracking the hard-coded home location (deletes the above mentioned file).

To make sure that it’s not that easy to mess up the location save, Dorothy checks for a touch sensor on start. If there’s no touch sensor then the internal pull-up shows a “HIGH” value, and in that case turn off the sensor monitoring code. That means no home location save until the board is restarted with a touch sensor attached.

The source code for all this is available on Github! It is based on the GPS demo included in the LinkIt One SDK, just heavily modified.

Future

It was an interesting first project with this board. Probably Dorothy will stop here, most other changes I can think of are more “complications” than “improvements”, so probably not worth doing at this stage. I’d love to hear suggestions, though!

For the board so far my impression is quite positive, even though there are some difficult issues remaining:

• there’s no Linux support for the SDK (only Windows and Mac), though I guess it’s more of a choice than a fundamental problem. The only parts of the SDK that is probably not available for Linux is the firmware flasher – which does not work for me on Windows anyways. The IDE is based on Arduino so that should be fine, the compiler is gcc (I think) so that’s fine too….
• the SDK documentation is quite patchy. Can’t use the API docs by themselves as not everything is explained. For many things I have to look at the examples directly, and even then it’s more trial & error
• the hardware bugs like the over-eager pull-up are annoying (and harder to debug than software bugs)

But there are other stuff that makes me want to try more things out:

• onboard SD card is cool (even if cannot be used in the same time as the internal flash)
• onboard audio, WiFi, Bluetooth are also very cool
• the battery is very useful, will try to measure how long it can last and build some projects around that.

From LinkIt One’s messaging I see they want it to be the ultimate prototyping platform for Wearables and IoT. I don’t think it’s the ultimate one, but definitely a very handy tool.

And this was a fun project. My homesickness has abated a bit too, which is nice. :)

The post Dorothy – a project for those away from home appeared first on ClickedyClick.

Idea

Looking at the mini-PCIe specs, the connector has mandatory USB 2.0 lines so communication was solved. The area available, roughly 5.1 x 3.0 cm, is not too bad  -more than how big the Arduino Nano is in comparison. The biggest challenge probably was that there are only 3.3V power lines available, and most example designs use 5V power supply.

Fortunately Arduino is released under quite permissive Creative Commons CC-BY-SA license, which means whoever makes an Arduino clone, also has to release it under the same license. This gave a lot of interesting designs to scout and learn from.

The original plan was using a similar Bill of Materials as the Nano, based around the ATmega328P, but two things happened to change it. First, I’ve changed my mind that I didn’t want to use the FTDI FT232 chip they used for USB-to-UART conversion. Second, my clever electronics friend Niko figured out that the tiny bit more advanced ATmega32U4 microcontroller would also work at 3.3V and since it speaks USB natively, could cut a bunch of components (that’s always good). The trade-off is a bit of clock speed (running at 8MHz), but that’s acceptable.

Design

I did find clone with these parameters (3.3V power and ATmega32U4), the SparkFun Pro Micro 3.3V.  Took that basic design, replaced some components, added a Power LED,  and broke out the pins differently. Done in KiCad, the result is this PCIeDuino design below (or check the PDF version).

The next step was fitting all these components onto a mini-PCIe card. The board size was sketched in detail in the specs, though somehow all the dimensions were described in a way that it was quite inconvenient for making a board outline. Nothing that an hour of math cannot fix…

Actually, had to do the board layout twice, because for the first prototype (that I actually got printed) somehow had a crystal footprint that doesn’t correspond to any available 8Mhz crystal that I needed – so had to start again a bit. I took that chance to reorganize the board bit, and that extra round of design did a lot of good to the quality! More logical layout, better component grouping, simplified arrangement.

The biggest challenge at this stage was wiring the output pins. That part was done with a few tries of autorouting with FreeRouting. The idea being that it’s a low frequency, small board so likely not too demanding design-wise, and getting it printed is more important that fine-tuning it to death. The USB line was hand-matched, though, and the LEDs were arranged to face the same way for easier mounting, so not all just auto-optimize.

The tape-out happened in May, about 9 months after getting started (and about 4 months downtime in between). The resulting board looks like this:

I’ve submitted the board to Seeed Studio’s Fusion PCB service, and got it back in about 2 weeks. In the meantime the components were ordered from Mouser, the parts for 10 boards (equal to the number of PCBs printed)  just being above the minimum threshold for free shipping.

Alive

Then came the assembly – hand soldered surface mount components can be really frustrating, but I really got to like them by now. If only my left hand was better (I’m right handed – solder in right hand, tweezers supposed to be in left). The assembly took about 1 hour altogether.

Now it’s time for waking the board up. Fortunately SparkFun’s Pro Micro firmware fits nicely onto the PCIeDuino too. Using an USBTinyISP clone (from eBay), a bunch of pogo pins, and the ISP headers on the board I could flash the firmware.

Plug it into the the embedded board and powering up, the blinking D13 LED showed that everything should be pretty close to alright!

Since then I’ve assembled altogether 7 of the boards (still takes about 1 hour each by hand, but I’m getting better). Had a few failures, but now I also know how to diagnose those issues better.

(If curious, so far had “magic smoke”, cold joint, shorted microcontroller pins, and now a board with a short somewhere that triggered the fuse. Ah, the learning!)

Advanced

Now the PCIeDuino is available on Tindie (whenever I have a bit of time to assemble more). It a great experience trying to make a compelling maker project that other people want to use too! Having better documentation, more explanation, better software, better communication, and actually going out finding people who are interested in this could be pretty much full time work!

I got my first Hackaday feature too, not that it was a great article, but the discussion was very illuminating and helped me to polish my own idea regarding this project.

All the KiCAd source and Gerber files are available on Github with CC-BY-SA license, so others can take this design to places too!

Future

The PCIeDuino is still very much a prototype project, more suitable probably for advanced users who are not put off when not every path is well worn out. I have to test it a lot more too, and find interesting use cases!

It looks like that the SparkFun firmware is not very well maintained, and it could be useful to look for alternatives. Optiboot seems to be interesting, but it also needs some work for the ATmega32U4 chip. Software support is super important, though, so this got to be a high priority improvement.

The original idea was to use this on embedded boards, that are mostly ARM systems. It should also be easy to use, Arduino IDE compatible project. The problem is, that the two parts are at odds with each other. The Arduino IDE doesn’t quite work well on ARM yet, so it’s mostly command line operation at the moment. Not a breaking change, but still a fail that needs to be remedied somehow.

The board is designed to conform to the mini-PCIe board specs. It fulfills the full-sized board variation’s requirements: the board outline, 1.0mm PCB thickness, connector pins,  mounting, keep out zones, …. It does not do the beveled cut at the connector (45º bevel cut needed, but seems to work regardless). To help other people to design mini-PCIe boards, I’ve put together a bare board starter kit in KiCad, available on Github, which includes the connector schematic, board outline, pin placement, and top-end mounting holes. Would be good to make a half-sized board variation design as well in the future, though at the moment it’s not a priority (pull requests welcome!)

This project also gave me a lot of ideas for future devices: similar mini-PCIe designs with ATXmega or ARM Cortex-M microcontrollers, and other Arduino clones with special functionality, e.g. built around the ATmega2564RF2 for  802.15.4 mesh networking… But first, take this design to its full potential…

If you like this idea, check out the PCIeDuino on Tindie, and would love to hear any kind of feedback or comment too! There’s a lot to improve, even if this is really the most complex electronics design I made so far… Now back to the drawing board and to soldering!

The post My first non-trivial hardware: PCIeDuino appeared first on ClickedyClick.

Working on quite a few hardware projects these days, I started to wonder (okay, say it out loud: worry), that there’s an uncanny valley for hardware projects as well. My theory goes such that hardware projects that are almost, but not completely professional can be more off-putting (or underwhelming) than less advanced, clearly maker projects and prototypes.

To give a few examples of cases that I feel might fall into this uncanny valley:

• a gadget that moved on to more advanced, surface-mount components, but they are hand-soldered (instead of done with a reflow oven). Functionality is the same (hopefully), but the visual appearance is always a bit less organized
• a project that has very detailed documentation, but not quite a complete manual, leaving just enough uncertainty to possibly frustrate some semi-advanced users
• packaging / invoice done nicely but not as good or clear or standardized as e.g. a Mouser order (just as an example), going overboard with what to include or not going far enough (quick start guide, any help, disclaimers, policies – are they needed, and if yes, in what depth to cover the topic?)
• communication is more polished but still fall short of professional customer service in clarity, or hitting the right tone, or being too corporate-y (or too little), taking just a bit too much time to reply to questions, and so on….

I guess many of these issues arise around the time when makers want to start earning a few buck with their work, and not everyone is prepared to cross this region of professionalism. But if there’s a valley, you’d better stay on the low side, or fight through to the upside with plenty of effort.

If there’s a valley like that, I guess it’s still a good problem to have, and platforms like Tindie (the indie hardware marketplace) do a good job of throwing people into the deep end into these issues. I myself trying to figure out whether I’m in there yet (and whether I’m making progress). I might just be overthinking this…

So what do you think, is there such an Uncanny valley for hardware? If there is, have you experienced and survived it? (any advice if you did?;)

Edit (2015 Aug 28): this post got a surprise mention on The Amp Hour podcast where Chris Gammell of Contextual Electronics and Dave Jones of EEVblog discuss all things electronics. Glad they (pretty strongly) disagreed, that means I’m overthinking it for the lack of experience (compared to them for sure). The part about this is between 5:00-15:00, but the whole podcast is good! (And I’m fan of their sites too:) Cheers~

The post Is there an Uncanny Valley for hardware projects? appeared first on ClickedyClick.

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!

Here is it in action:

Hardware

For this I’ve used parts that were pretty much lying around in the Hackerspace:

• an Intel Edison, then added…
• an Android Breakout Board,
• a Grove Base Shield
• a Grove RGB-LCD (that is controlled over the I2C lines)
• a Grove LED (on one of the digital pins)

I’ve started a new project in the Resin.io interface based on Edison. Downloaded their image (and checked out getting started guide), flashed it onto the board through the Android breakout board, and it was ready to get some code on (well, kinda).

Software

In the docs I’ve found that there’s a specific docker starter container made by the Resin team for Python code, and that looked like a good point to start off from.

First I was thinking using the default mraa library that Intel provides for the low level I/O, but fortunately also found UPM, a higher level library that already supports a lot of sensors and I/O – including the RGB-LCD! That saves a lot of time indeed, and has both Python and Node.js API for quicker code (besides the base C++).

Mraa is already installed on the base image, but UPM had to be added manually to the Dockerfile.

The base function of the code is crystallized out as:

• connect to a specified IRC server and join a specific channel
• listen to the messages there
• on the LCD display the messages as:
  • first line shows the user that posted
  • second line is the message posted, if longer than the width of the LCD then scroll it
  • to quickly distinguish between people, assign different colours to the different users
• blink the LED on new messages
• keep doing this…

Straightforward enough?

I’ve used the irc library in Python to create a simple IRC bot that listens to the channel and does the required I/O. Needed some code digging (because it’s not too — khm — well documented), for example to enable SSL connection for the bot part of the code (for using port 7070 on Freenode). In the end indeed “use the source, Luke!”, as they write and it worked out.

The I/O part needed to be parallelized too, there used some part of the multiprocessing library that I haven’t used before (Process), and some data sharing: the display can run and scroll the text, while the bot can notify the display’s process when it needs to show something new. Same for notifying the LED, when it needs to blink.

For doing different colours for the different usernames I use hashing: run the username through SHA256, and use the 1st, 2nd, 3rd bytes of the resulting has as Red/Green/Blue for the backlight colour.

Here’s the code in Python (2.x):

import hashlib
username = "MrEdison"
h = hashlib.sha256()
h.update(username)
ColorR = int(h.hexdigest()[0:2], 16)
ColorG = int(h.hexdigest()[2:4], 16)
ColorB = int(h.hexdigest()[4:6], 16)
# (ColorR, ColorG, ColorB) = (115, 126, 15) or #737EF

the result:

Works pretty well!

The bot’s settings (server name, port, channel, nickname) are all set through the Resin.io control panel as environment variables.

Environmental variables used at the moment:

• SERVER: the IRC server used, defaults to irc.freenet.net
• PORT: port used, has to be SSL-enabled, defaults to 6697
• CHANNEL: which channel to connect to, together with all the hashes, defaults to #mredison
• NICK: nick to choose, no authentication yet, defaults to mredison
• TIMEZONE: what timezone to display updates in standard tz database notation, defaults to UTC

This makes it quite flexible, can let the bot/setup monitor any channel on any network, though at the moment needs SSL-enabled server, but that’s easy enough to change if someone wants to run the code and don’t care about security… :P

For testing I was using mostly the #ubuntu and ##linux channels, as they seems to be pretty chatty!

Experience

It was a bit bumpy process, like most experimental works. First I’ve run into some Edison/Docker related strangeness that messed with the I/O. Solved by Shaun from Resin, the trick being needing to mount the debugfs before running my code, so the kernel can configure things correctly:

mount -t debugfs nodev /sys/kernel/debug

Edit (8/1): This in the end wasn’t enough, had to go back to the Edison GPIO Pin Muxing Guide, and turned their Example 4: Configure IO18/IO19 for I2C connectivity guide into a pretty hard core, but probably well commented bash script to set up I2C, which is called on start. Seems to work out!

There was also some issue with the bot timing out in a strange way and losing connection. I was about to rewrite the whole code in Node.js, but tried a quick client test first. Turns out that I was testing on port 6697 (which is I read the default SSL port), and that has some connection issues. After I’ve switched to 7070, all of that disappeared, and the connection seems pretty solid (no timeout so far).

There are some bugs that remain, though:

• Unicode handling is non-existent, so those posts can pretty much mess up the display
• There can be race conditions using the display, not the best threading code probably…
• At bootup, the LCD display is borked, but after adjusting the environment variables (without reboot), things sort themselves out! Maybe need to tweak the startup script and add some delay between the steps?

Otherwise it’s working pretty well, the colour changes are fun, the text is readable, so I guess mission is accomplished!

The source code is on Github, and to set up your own version of this, just create a new Edison project, flash the system, clone the source code and push it to your application, finally define the environment variables SERVER, PORT, CHANNEL, NICK as they are suitable for you, and enjoy!

Future

It would be probably good to create an enclosure for this setup, to hold the parts together more securely. Then drop it in the Hackerspace and set it up to listen to our IRC channel – and get chatting.

It’s probably unlikely that I’ll change much on it in the future, most I can think of is adding some more bells & whistles (or rather, literally a buzzer:), but that might be too much. The code works well enough, but pull requests are accepted!

I’m mostly just glad that the idea worked out, and the project is done. Now I can actually move onto another one (there are way too many projects on the waiting list, driving me nuts)….

What’s your take on IRC? Do you use it? Would this project be useful for you somehow?

This project is also written up on hackster.io.

The post A window to IRC with Edison and Resin appeared first on ClickedyClick.

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.

The drivebox contains an electronic circuit and a couple of cogwheels to turn the DC solar power into motion somehow. Originally the solar panel was not detached from the circuit board as it seems above, just after messing around with it for a while it came off…

Electronics

The circuit has only a handful of components and they looked reasonably intact (some surface corrosion on the capacitors and lot of grime on the transistors, but nothing that seems to be a showstopper). The round black thing on the right is a spool of thin, enamel coated wires  – a custom inductor. The wires were spun in both directions, so it is actually two inductors intertwined.  The transistors are C945 according to their marking (or 2SC945 in it’s full name, as I’ve been told). The two lines leaving the photo to the left connect to the solar panel.

The bottom of the circuit. From here it can be reverse engineered to see how does it actually work. The enamel coated wires were freaky to have a lot of extra length after their soldering point and been all over the circuit. Probably that would be good to cut short to make sure they don’t cause any shorts in the future… The resistors were desoldered so I can check their component value, the capacitor values were read off their housing, the inductor I didn’t touch this time, so their value is an outstanding question…

To figure out what the circuit does, it  helps to transcribe the diagram into schematic well. Then I messed up the legs of the transistors in the up-down flipping multiple times, so the circuit came out all wrong. Fortunately JohnnyThree at Reddit AskElectronics helped (may he be blessed with lot of karma!:), not just to correctly transcribe the circuit but arrange the components so that it shows what the circuit really is: a variation on an astable multivibrator.

I fixed up the circuit in KiCAD (good learning experience as well, and go open source!). The difference between the regular astable multivibrator and this circuit is C3 capacitor between the base and collector of Q2 (according to JohnnyThree it’s to curb RF interference), and using inductors L1 and L2 instead of pure resistors.

Here are some additional resources if anyone’s interested:

• Schematics in PDF format
• KiCAD/eeschema schematic and component library

Been checking some of the components separately as well when trying to figure out what was going wrong. The solar panel has VIMUN SC-5528 marking on it, which would make it a 1.5V poor light type amorphous silicon solar cell. This would make a lot of sense for home electronics, poor light is basically every light. When using my smartphone’s flash as a light, I could drive it up to 2.9V output at full power, but normally was much less.

Since the solar panel’s connections came off the board after a while, I resoldered them, and could measure with a multimeter that the circuit does something. When connected, the voltage across solar panel maxed out around 1.VV, and the voltage across either of the inductors seemed to be oscillating between 0.3V and 1.0V with a period of about 5s. Not sure if this is any useful, just noted.

When I’ve put the wheel with the magnets attached back in place over the coil, it was moving a bit back and forth with the 5s period. I thought maybe the device is back to normal after reattaching the solar panel and time to reassemble.

Reassembly

It was time to check out whether the setup was actually working and put everything back together. The wheels were pretty hard to test when not held at their place by the drivebox’s top.

Before I’ve put the cogwheels back to the box, I’ve counted their gear ratios. The magnetic wheel has 10 teeth, the middle wheel has 70 / 12 teeth (in / out), and the final has 70 teeth again. That would mean a (70/10) × (70/12) = 7 × 5 = 35 gear ratio, I guess. The teeth on one wheel seemed not symmetric which ends up forcing the prayer wheel to only turn in one direction.

After putting the box back together, I’ve tried illuminating the solar panel with the flashlight again and see what happens. With a little initial turn the square drive shaft (is that what the thing is called, by the way?) it did start to rotate by itself pretty well! We are on the right track.

The biggest difficulty putting the parts back into the box was keeping the ballast stones from dropping on the solar panel and crashing it. A little careful handling and everything’s back in place.

Finally I could test the whole assembly. Looks like the essential ingredients are sufficient light and an initial push. Not sure if the need for the initial push is intended or just a side-effect, but it actually mimics very well the existing physical Tibetan prayer wheels where one has to set them in motion, and the intention does count for the religious purposes. Though as a note, if the light is strong enough (full blast flashlight from up close), the wheel does start by itself and goes into pretty fast spin!

The prayer wheel part of the assembly has a lot more inertia than the driveshaft on its own, and this it the wheel turns slower than I’ve seen in the earlier test, and stops much quicker when the light is cut off.

In the video I test the wheel out, kickstarting it, blocking the light to see if it is really operating from the solar panel or just the initial kick keep it moving…. So far so good!

Future

A couple of things I can think of as future work with this gadget:

• Simulate the circuit in SPICE to understand the effect of the extra capacitor and the inductors
• Figure out whether it can it be fixed up to use less light? At the moment it’s not that easy to find a place around the house with sufficient natural light to make it work.
• Figure out if the friction on the wheels be reduced to make them turn easier / longer?
• What else could I hack this circuit to do?

And then again, what other gadget to take apart next time?

The post Solar powered Tibetan prayer wheel circuit appeared first on ClickedyClick.

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.

The size of the board is about the same as the Arduino Nano, but not pin-compatible. Navspark’s pins are multiplexed, and multifunctional.

When I first tried to set it up, I’ve run into some issues. The Navspark community site has a lot of information and many tools. I started at the resources page, downloading the User Manual and the customized Arduino IDE made for Navspark. First the IDE didn’t want to run on my 64bit Linux, but they figured it out and posted an update. Then flashing the code to the board failed with a mysterious error message, but they got that one working as well in the next update. This all took about a day, after which I could happily develop with my brand new board, awesome!

Beidou

When I chose my reward during the campaign, I went for the GPS/Beidou version because my HTC Butterfly already has GLONASS reception, and wanted to try something new. Beidou is an interesting because it just wants to be regional, as opposed to GPS, GLONASS, and the European Galileo positioning network that are all going global. Being regional then it can  use geostationary satellites, and fewer than the other networks.

When I was thinking what should be my first project, I thought I use Navspark to take a look at the Beidou satellites, how do they behave.

I’ve tried the antenna, and it worked (naturally) better being outside, I hung it up on the little balcony outside of my window. Compiled the “demo_how_to_extract_gps_info” sketch, and flashed it.

I needed a few tries to start receiving data from the board, but that’s just because my memory was rusty of all the tools needed under Linux to get and to understand GPS/positioning data. Reminded myself how to use gpsd, and gpsmon, but those understood only the GPS part.

Sidetrack: NMEA

When I started to use gpscat, to just split all the “NMEA sentences” (or fragments of data) from the receiver, everything started to make more sense. The NMEA sentences have a 3-letter identifier, what data should be in that sentence. For example the GGA sentence has the location information, while the GSV sentence lists detailed satellite info, or ZDA lists the date and time.

In front of that 3-letter identifier, though there’s 2 more letters, which I didn’t pay attention before, but now it makes sense: those can be used to denote which positioning network the data is coming from. When I looked at the logs, I’ve seen for example “GPGSV”, and “BDGSV” sentences – both are detailed satellite data, but one from the GPS (“GP”) satellites, while  the other from the Beidou (“BD”) satellites. I’ve seen also “GN” as 2-letter identifier, so that’s probably GLONASS. Since this receiver does not have that function, no actual data shows up in those sentences.

There’s a lot of NMEA sentence information online, for more details. As an example, here’s a sentence that lists the first 4 of the Beidou satellites found by the receiver:

$BDGSV,2,1,05,203,59,206,34,208,58,181,42,201,56,140,44,204,00,000,34*6D

Without going into too much detail, here’s what’s inside this line:

“203”, “208”, “201”, and “204” are the pseudo-random number generator  (PRN) code of 4 different satellites, basically a way to identify them. For the GPS network, PRN goes from 1-32, so anything above that is something else. GLONASS has reserved the numbers between 66-85 (will have to check this with my Butterfly). These 200+ numbers are again a different network, the Beidou satellites (though I haven’t found any source yet that spells them out directly).

The 3 numbers after each PRN code is the “elevation” (degree over the horizon), “azimuth” (horizontal direction in degrees), and signal-to-noise ratio (SNR) of the reception. For example satellite 203 has from my location elevation 59°, direction 206° (south-by-south-west), and SNR of 34. The satellite 204 has 0 for elevation and azimuth, meaning it hasn’t been figured out by the system yet.

Recording

I’ve used gpscat to record some (so far about 8 hours) of satellite tracking data, all the NMEA sentences coming out of Navspark. When plugged in, the receiver showed up at /dev/ttyUSB0, and the incoming data stream was correctly received and logged with the command:

gpscat -s 115200N1 /dev/ttyUSBx > navspark.log

Here the “-s” command sets a speed (baud rate) for the USB-serial connection to 115200 bits per second. The “N1” part sets No Parity, 1 stop bit, which is usually the case.. Sometime I could communicate without this setting, but often the wrong baud rate was detected, so I guessed that this receiver likes the highest speed that usually occurs (this 115200 baud rate). Finally, all the output is directed into the “navspark.log”file.

The 8 hours of data adds up to about 15Mb text, and I’ve written a Python script to extract the GPS and Beidou satellite location data. Another python script is used to visualize the tracks on the sky above with Matplotlib. The scripts used can be found in the supplementary files section.

First the GPS tracks. This is quite familiar, fast lines across the sky.

On the image 0° is North, 180° is South, and so on. The centre of the image is right above my location, while the edge of the circle is on the horizon. The satellites are filtered to only show the ones with more than 3000 records, but it’s still a big mess. This is definitely not my greatest plot ever, but it more or less does the job.

Then I’ve plotted the Beidou tracks too. Similar filter is applied, except for the satellite with PRN 209, that I included as well with fewer records. The tracks look like this:

The thing that should stand out is not that there are fewer tracks (of course, since there are fewer Beidou satellites), but that there are two very distinct behaviour.

Satellites 201, 203 and 204 stay pretty much at the same place (geostationary orbit), while 206, 207, 208, 209, 210 are tracing out a path.

Now trying to match this information up with the list of satellites on the Beidou Wikipedia page, I get the following conclusions:

PRN 201, 203, and 204 should correspond to Compass-G1, Compass-G3, and Compass-G4 geostationary satellites. I haven’t double-checked where their location should be visible from here, but their East-West ordering in the group is correct according to this hypothesis. If that’s so, there still should be a PRN 205 (Compass-G5 although might not be visible from here), and no PRN 202 (Compass-G2 is not functioning). Not sure what number the latest geostationary Compass-G6 should have, because PRN 206 is already in use.

PRN 206, 207, and 208 seem to be on the same loop (the three colours adding up to a single loop-of-8). Then these could very well be the Compass-IGSO1, -IGSO2, and -IGSO3 satellites which fly a geosynchronous orbit at “118°E with inclination 55°”. Not sure yet how that orbit should look like, but the position of their loop compared to the geostationary satellites looks promising.

PRN 209 and 210 also seem to be of the same loop, so probably Compass-IGSO4, and -IGSO5, on a geosynchronous orbit “95°E with inclination 55°”.

It’s pretty cool that from a mere few hours of recording we can identify all the Beidou satellites.

An extra mystery

If I check the GPS tracks closely, there are two satellites with code 42 and 50 that don’t look GPS, but geostationary. A bit of search into what they might be showed that they are are the pair of Multi-functional Satellite Augmentation System birds from Japan, to supplement the GPS network. 42 and 50 are their NMEA code, which is equal to PRN-87, so I might have been misusing the “PRN code” terminology, but maybe not too much.

There’s one more satellite with PRN 193 that is out of ordinary. That shows up in a document as Quasi-Zenith Satellite System SV 1 bird. That system is for time transfer, and also to further improve GPS over Japan.

It’s interesting that this receiver can find them. And I guess the Japanese space program does worth to take a deeper look at!

What to do next?

This is a good first experiment, because there are a lot of questions answered, while almost as many new questions popped up. Already have more ideas what to do than time to do it.

• Should compare the position accuracy of this receiver and one of the other USB GPS receivers I have. Not totally fair, because they kinda have a more complete antenna, but maybe under open sky it would work.
• Figure out how GPS and Beidou satellites are used together to get a location. Are they? Or separately?
• Try out the other Navspark functions, which there are many! The examples show ADC, timestamping, SPI, two-wire, 400KHz PWM output. It’s also running on higher frequency (100MHz?) and more program memory (1Mb?) than Arduino.
• Try other programs now playing with GPS, for example gpredict (orbital prediction and tracking). If they don’t have support for Beidou, maybe can try add to them?
• Find my Orbital Mechanics for Engineering Students book, and get learning!

What would you like to do with such hard core geo-positioning tool?

The post Navspark: Arduino for GPS, GLONASS, and Beidou appeared first on ClickedyClick.

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.

The Server

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

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:

On Linux:

• 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.

On Android:

• 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).

IAX

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)
• Could script a lot more too via the Asterisk Gateway Interface (AGI).
• 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.

The post Personal phone server, or Can you hear me now? appeared first on ClickedyClick.