Zedstar Dot Org http://zedstar.org/blog Tue, 19 Apr 2016 07:59:52 +0000 en-US hourly 1 http://wordpress.org/?v=4.3 Nibble I/O app http://zedstar.org/blog/index.php/2016/04/19/nibble-io-app/ http://zedstar.org/blog/index.php/2016/04/19/nibble-io-app/#comments Tue, 19 Apr 2016 07:59:52 +0000 http://zedstar.org/blog/?p=321 I have released a universal app for iOS for sharing Apple Contact information between devices. The application uses sound to broadcast from one device to many. Watch support and Mac support coming soon.

For more details visit http://nibble.io

]]>
http://zedstar.org/blog/index.php/2016/04/19/nibble-io-app/feed/ 0
Communicating XML concisely using Swift http://zedstar.org/blog/index.php/2015/05/24/communicating-xml-concisely-using-swift/ http://zedstar.org/blog/index.php/2015/05/24/communicating-xml-concisely-using-swift/#comments Sun, 24 May 2015 13:24:14 +0000 http://zedstar.org/blog/?p=316 Some background…

There are plenty of XML haters out there but this is a great quote:

XML is like violence: if it doesn’t solve your problem, you aren’t using enough of it.

Having spent quite a bit of time working with Lisp-like languages I am used to feeling syntax-fuelled hate. However, if what I send across the wire is not XML but something very concise I am not overly bothered about syntax. I will use XML, JSON, S-expressions, or whatever, as long as there are decent parsers. There have been numerous attempts to invent a new markup language or abstract syntax to represent the same kinds of data. When it comes to concisely transferring this data over a network you can adopt two approaches. You can send everything in one message or you can separate out the data you need to communicate from the structure and types but still allow the data to be reconstructed by the receiver. So you could take a chunk of markup and apply some text compression to it and send that binary across your network or you could send a minimal amount of data encoded into binary that relies on a schema or protocol to reconstruct it. The latter has the advantage of allowing the schema to be used multiple times on different sets of data as long as they conform to the schema. This means you can not only send less data but you can take advantage of fast encode/decode cycles by processing the schema once at startup and using that optimised version each time you encode and decode. This also provides the added benefit of allowing validation to take place on each encode and decode, something that text compression has no clue about. ASN.1 led the way in this approach. It was very powerful but complex which made tool support challenging. Google’s Protocol Buffers follows a similar approach but has a less abstract syntax to provide an easier way to map the data and types to programming languages. In the XML world there have been many attempts at compressing this verbose markup. In the end EXI emerged as the standard approach. However, I think the design is also flawed. In my opinion EXI suffers from the same problems as ASN.1, being overly complex to implement. That means you will struggle to find credible implementations outside of enterprise computing. I also don’t think it makes sense to try and invent a general serialisation approach to XML because there are too many caveats. At some point you will give in and employ text compression instead. So when I decided to make an XML serialisation tool I wanted to recognise these limitations. Packedobjects was based on ASN.1 but represented in a subset of XML Schema. It has a limited set of data types that are enough to write network protocols. It deliberately restricted XML Schema to control things like the order of data and the way data repeated. For example, I don’t think it makes much sense to support a set data type when machines are pretty good at generating things in the same order each time.

Going mobile…

If you are working on restricted platforms such as mobile or embedded devices, in the end it is all about tool support. This is where I believe XML does well. If you want to support parsing a schema language efficiently you probably have few options. Libxml2 does a great job of this and it does it quickly. What’s more, this parser is everywhere. For example, it can be in your pocket right now if you own an iPhone. I decided to see how Packedobjects would perform on iOS if I wrapped the current API in a more high-level interface that worked with strings rather than expose the more lower-level Libxml2 doc type API. The porting process was fairly quick and painless. I built an example program that can take all the XML files in the Packedobjects repository and ran them to get performance metrics.

IMG_0667 IMG_0668
The screenshots show the results running on a 5th gen iPod. This example is available to try out here. There is quite a big discrepancy between encoding and decoding speed performance but overall I am pleased at how the tool performs on the devices I tried. I will be adding support for 64bit encoding and decoding soon to see what impact this has on an iPhone 6.

Size matters…

One thing I avoided talking about in this post until now is the key metric of encoding size. Rather than believe what I say you need to pick your data set and try for yourself. For the type of data I work with, Packedobjects outperforms other approaches I tried. I would classify this data as highly structured and not dominated by string data types. So the kind of data that might originate from the Internet Of Things (IoT), sensor networks, network management and so on.

]]>
http://zedstar.org/blog/index.php/2015/05/24/communicating-xml-concisely-using-swift/feed/ 0
Nibble running on a Pi 2 with 2.2″ TFT http://zedstar.org/blog/index.php/2015/03/27/nibble-running-on-a-pi-2-with-2-2-tft/ http://zedstar.org/blog/index.php/2015/03/27/nibble-running-on-a-pi-2-with-2-2-tft/#comments Fri, 27 Mar 2015 19:01:27 +0000 http://zedstar.org/blog/?p=310 The speed bump of the Pi 2 means that nibble.io will run at similar speeds to the Banana Pi. I got of a 2.2″ TFT and soldered it onto the Pi and made a quick video. The only additional hardware used is a small USB microphone.

]]>
http://zedstar.org/blog/index.php/2015/03/27/nibble-running-on-a-pi-2-with-2-2-tft/feed/ 0
NibbleKiosk: controlling chromium through sound http://zedstar.org/blog/index.php/2014/08/25/nibblekiosk-controlling-chromium-through-sound/ http://zedstar.org/blog/index.php/2014/08/25/nibblekiosk-controlling-chromium-through-sound/#comments Mon, 25 Aug 2014 18:11:42 +0000 http://zedstar.org/blog/?p=291 **updated for verison 0.0.2**

The idea of NibbleKiosk is to turn old monitors into interactive displays using simple hardware such as a Raspberry Pi with a microphone. The sounds received by the microphone are turned into URLs and sent to Chromium browser. The software comes with 3 programs:

  • one to create the sound files based on the URLs to be used by the client
  • one to create a database of URLs
  • the main program which does the signal processing and controlling of Chromium

You first need to create a database of URLs:

nibbledb -u http://www.raspberrypi.org -d test.db

which outputs:

test.db: key 1B95FB47 set to http://www.raspberrypi.org

You can then create a sound file to use to trigger the URL:

nibblewav 1B95FB47

This will output a wav file with the same hex code in lowercase to your /tmp directory

aplay /tmp/1b95fb47.wav

and you should hear what it sounds like.

You can now start the main program on the receiver. You should first start Chromium listening on port 9222

chromium-browser --remote-debugging-port=9222&

You are now ready to start the main program with the database you created earlier:

nibblekiosk -d test.db

This should now listen continually for the right sounds to trigger URLs on Chromium. You can build your own clients with the wav files you generate.

There are number of variables to get a functioning system. A key variable is getting the right signal magnitude to trigger the system. You can use the -m flag to experiement with this. On a Raspberry Pi I have set this as low as -m 2, e.g.

nibblekiosk -d test.db -m 2

I have had good performance from the microphone on an old USB webcam or if you want something small for the Pi, Konobo makes a very small USB microphone.

If you are feeling brave and want to try I have made some packages for Ubuntu (14.04) and Raspbian:

http://nibble.io/testing/deb/

The only dependencies are OpenAL and Berkeley DB.

]]>
http://zedstar.org/blog/index.php/2014/08/25/nibblekiosk-controlling-chromium-through-sound/feed/ 0
nibble.io http://zedstar.org/blog/index.php/2014/03/03/nibble-io/ http://zedstar.org/blog/index.php/2014/03/03/nibble-io/#comments Mon, 03 Mar 2014 20:44:48 +0000 http://zedstar.org/blog/?p=288 I have been working on applications that can transfer data using sound on mobile and embedded devices. The first product I have created is called NibblePin which is specifically designed to exchange BBM PINs.  All signal processing is done on the device and the implementation is portable across a range of embedded hardware.  The first port of this application is for Blackberry 10 but I will work on some other mobile OSes and platforms. For further updates check out http://nibble.io

]]>
http://zedstar.org/blog/index.php/2014/03/03/nibble-io/feed/ 0
XML over DTMF http://zedstar.org/blog/index.php/2013/01/04/xml-over-dtmf/ http://zedstar.org/blog/index.php/2013/01/04/xml-over-dtmf/#comments Fri, 04 Jan 2013 16:46:50 +0000 http://zedstar.org/blog/?p=283 Some hardware such as the Ben Nanonote or Dingoo A320 come with no built-in RF capabilities. However, they both contain microphones and speakers which opens up the possibility of transferring small amounts of data over sound. This type of communication is challenging due to the bandwidth constraints and noisey channel. I am interested in communicating structured data across such environments. XML is a decent way to structure data, providing you can minimise the transmission overhead. Using XML Schema, Packedobjects can support the levels of compression required to make usable applications. Generating and processing sound can also be challenging but we can reuse existing technology such as DTMF. By combining some of these technologies I have created a library which allows you to build simple applications which can communicate XML over DTMF. Currently you can transfer XML data from the headphone socket of one device using an audio cable to the microphone socket of another device. You can see an example of this setup in the first image. Here the software is communicating XML from a Ben Nanonote to my Macbook. The other images show the commands to run on the Nanonote and Macbook and their outputs. Using an audio cable from an embedded device is limited but has some niche applications because it is simple, cheap and has minimal setup. More interesting applications exist if you transfer the sound over longer distances, eg. through phone lines, or if you actually use air as the transmission channel. A noisey channel will require forward error correction (FEC). A fun challenge will be to find a FEC technique that works well on an embedded device across this noisey channel without significantly increasing the size of the data to transmit. Intially I had some FEC code integrated in the library but think it will be better if something like libFEC existed.

The project is called nibble and the source code is available here: http://code.google.com/p/libnibble/

If you have a Ben Nanonote you can get all the required packages here: http://zedstar.org/nibble/. On the Nanonote you will probably need the ALSA config file listed there called asound to fix some playback issues. Just copy it to ~/.soundrc

For a simple test setup just loopback an audio cable from headphone to microphone on a PC running Linux. The spandsp library has a hard limit of 128 DTMF digits set in dtmf.h. This is patched in the Nanonote build.

]]>
http://zedstar.org/blog/index.php/2013/01/04/xml-over-dtmf/feed/ 0
packedobjects XML compression on a Dingoo A320 http://zedstar.org/blog/index.php/2012/12/22/packedobjects-xml-compression-on-a-dingoo-a320/ http://zedstar.org/blog/index.php/2012/12/22/packedobjects-xml-compression-on-a-dingoo-a320/#comments Sat, 22 Dec 2012 16:43:05 +0000 http://zedstar.org/blog/?p=272 ------------------------- ^__^ (oo)_______ (__) )/ ||----w | || || opendingux:/boot/local/home […]]]> The only library libpackedobjects depends on is libxml2, therefore, it should port to all kinds of devices. Here it is running on a MIPS-based Dingoo A320:

john@macbook:~/git/gitorious/libpackedobjects$ telnet 10.1.0.2
Trying 10.1.0.2...
Connected to 10.1.0.2.
Escape character is '^]'.

 _________________________
< Welcome to OpenDingux ! >
 -------------------------
           ^__^
           (oo)_______
            (__)       )/
                ||----w |
                ||     ||

opendingux:/boot/local/home # wc -c menu.xml
860 menu.xml
opendingux:/boot/local/home # packedobjects --schema menu.xsd --in menu.xml --out menu.po
opendingux:/boot/local/home # wc -c menu.po
11 menu.po
opendingux:/boot/local/home # gzip menu.xml
opendingux:/boot/local/home # wc -c menu.xml.gz 
310 menu.xml.gz
opendingux:/boot/local/home #

The example rootfs used is available here.

]]>
http://zedstar.org/blog/index.php/2012/12/22/packedobjects-xml-compression-on-a-dingoo-a320/feed/ 0
XML Compression with libpackedobjects http://zedstar.org/blog/index.php/2012/09/15/xml-compression-with-libpackedobjects/ http://zedstar.org/blog/index.php/2012/09/15/xml-compression-with-libpackedobjects/#comments Sat, 15 Sep 2012 08:32:33 +0000 http://zedstar.org/blog/?p=263 libpackedobjects is a C library based on libxml2 which provides XML compression and validation.

libpackedobjects provides a good range of data types for writing network protocols for application in areas such as network management over a wireless embedded internet.

libpackedobjects will run on anything that runs libxml2 such as the Raspberry Pi or iPhone.

A preview release (0.0.1) is available at packedobjects.org

 

 

]]>
http://zedstar.org/blog/index.php/2012/09/15/xml-compression-with-libpackedobjects/feed/ 0
An XML Compression Scheme http://zedstar.org/blog/index.php/2012/03/16/an-xml-compression-scheme/ http://zedstar.org/blog/index.php/2012/03/16/an-xml-compression-scheme/#comments Fri, 16 Mar 2012 15:05:15 +0000 http://zedstar.org/blog/?p=251 There are different ways of compressing XML but I like the idea of doing it with a schema. Using a schema you always have the advantage of validation but you can also produce very efficient encoding of the XML data. I have been working on an XML layer for packedobjects to allow compression of XML data. Currently it takes XML data with a schema written in packedobjects and produces binary data. This is very similar to XER but everything happens at runtime. This means I could support a subset of XML Schema and dynamically map to the packedobjects schema. Doing this the end user will only see an XML world.  Everything is handled by embedding Scheme to take care of the mapping between XML and s-expressions. From C you will not see this but you still have the advantage of working directly within a REPL to design your schema if you want. The Scheme layer could also be extended to handle other data formats.

Running the example will show that the packedobjects compression is about 3 times smaller than gzip based compression. In similar tests I have seen similar gains over encoding with Protocol Buffers.

 

]]>
http://zedstar.org/blog/index.php/2012/03/16/an-xml-compression-scheme/feed/ 0
TCR update http://zedstar.org/blog/index.php/2012/01/04/tcr-update/ http://zedstar.org/blog/index.php/2012/01/04/tcr-update/#comments Wed, 04 Jan 2012 14:23:38 +0000 http://zedstar.org/blog/?p=246 Building The Clashing Rocks prototype was fun. It really identified some brick wall challenges surrounding the quantity of data we had to process in real-time. Even encoding to bit-level was not going to cut it. As a result a new direction for the project will be to focus solely on recording the seismic events. This will provide more opportunity to implement techniques to work with the bandwidth constraints in place and will eliminate the hard real-time processing constraints. There will still be the challenge of synchronising, logging and presenting the data but we will focus more on providing high-level APIs and/or a DSL to help realise this. The project will still be OpenWrt based and run on different architectures.

]]>
http://zedstar.org/blog/index.php/2012/01/04/tcr-update/feed/ 0