Generating flight vouchers with LaTex

Learning LaTex was on my todo list for many years. Like most people of my generation, I learned wysiwyg text programs in school, and used them for a long time for most stuff that ended up on paper. Actually, to be exact, the first text processing program I learned in school didn’t fall into the wysiwyg category, but was DOS based. I think it’s name was “Farsight”, but I can’t find any information about it on the internet. Since I am no friend of proprietary lock-in systems, I switched from MS Word to OpenOffice a long time ago, and more recently to LibreOffice. But even though their file format is open, it’s still binary. I know, I know, Word and ODF offer textual formats. I think they are mostly XML based. But the last time, I looked at one of them, I could not believe how overloaded with useless trash they were. The most annoying limitation of binary formats, is when you want to store the documents in a version control system, and compare different revisions. I used html for a while for documentation purposes. Although it is very good for these textual diffs between revisions, I’m not artistic enough to make it good looking. Hence, I thought for a long time that LaTex would be worth learning.

Also, for a long time I wanted to automate the vouchers for our tandem flights at paraeasy.ch. Even-though I knew that this was a perfect match, I had too many other things to do. As I’m currently reading a book about LaTex, I have my perfect hands on exercise. Hence, I prepared a template tex file for the vouchers and one for the invoices. Then I wrapped a python script around, that handles the rest.

The traditional way to keep track of which vouchers are active, and which ones were redeemed, is to keep a list. But after reading all the buzz about smart property, I figured that BitCoin is actually a perfect solution in itself. I generate a unique BitCoin address for each voucher, and load it with some coins. That way I can easily check, if the voucher is still valid. In fact, even other pilots that fly for us, can easily verify the validity of our vouchers. Now the perfect solution would be to load it with the full value, but since the BitCoin price is still quite volatile, the risk would be too high. After all, I need to be able to pay other pilots in case of a BitCoin crash. So I decided to load the voucher addresses with half the value. That way I can better tackle the risk.

As an opensource believer, I pushed my scripts to github, hoping they might be useful for somebody. I didn’t go to full lengths, in making it a configurable drop in solution. So, if you want to use it, leave me a message, and I will help you set it all up, and make it more configurable along the way.

Now, what happens if somebody orders a flight voucher on paraeasy.ch?  After the customer fills in all the required fields, and presses submit, I receive an email with a html table containing all the information. I then save the mail with evolution to a folder as an mbox file. Next, I start the python script which performs the following:

  • Generates a new unique number for the voucher.
  • Parses the information from the mbox email file.
  • Generates a BitCoin address that contains the initials of the passenger.
  • Replaces the placeholders in the tex files with the actual information.
  • Generates a qr code with the relevant information, and a gpg signature thereof.
  • Generate pdf files for the voucher and invoice.
  • Add the new entry to the list of active vouchers.
  • Add the pdf files, the updated list as well as the encrypted private key for the BitCoin address to my private git repository.

The system is not finished yet, but it already looks like a big relief. In the future, it might also generate the email to send the pdf file back to the customer.

Pimp my miner

For a while now, I thought about mounting a simple display somewhere that shows the most important parameters of my BitCoin miner. First I started with an AtMega equipped with an Ethernet module. But parsing json without any library support became too cumbersome quickly. So I copy pasted together a small python script, and used a nokia display that I already equipped with an i2c interface. If I knew how easy it is, to use those json interfaces, I would have implemented this display project earlier. The code is at the bottom. It is specific to my setup with p2pool and CHF, but it is so easy to change that you can adapt it to whatever your setting is. The python script now runs on an Alix on the same i2c bus as my simple home automation transmitter. Now all that is left to do, is adding a line to /etc/crontab to execute the script once a minute.

As you can see on the image below, the hash rate is too hight for a stock Saturn. That is because I recently added an extension module. So it has now three instead of two hashing modules. All of a sudden, KncMiner announced they had 200 extension modules for the October batch, and that future modules would be incompatible. So, that was pretty much the only chance for an upgrade. My existing power supply should have room for one more module, and they were moderately priced. The demand was high enough that they were sold out in three minutes. The i30 cooler that was recommended was not available at the time, so I had to use an Xtreme rev2. I had a fun time finding out how to correctly mount it. Even for the original, there was no manual or description how to mount it. Just look at the existing modules said someone in the forum.

Continue reading “Pimp my miner”

Adding a display to rfid time tracking

More than a year ago, I blogged here about using RFID to track presence times in the BORM ERP system. I used the system a lot since then. But the BlinkM was really limited as the only immediate feedback channel. To use it with multiple users, a display was needed. The default Arduino compatible displays seemed a bit overpriced, and the Nokia phone that I disassembled didn’t have the same display as I used for the spectrum analyzer. But these displays are available for a bargain from china. The only problem was that the bifferboard didn’t have enough GPIO pins available to drive the “SPI plus extras” interface. But i2c was already configured for the BlinkM.

So, the most obvious solution was to use an AtMega8 as an intermediary. I defined a simple protocol and implemented it as i2c and uart on the AVR. I also wrote a small python class to interface it from the client side. As I buffer only one complete command, I had to add some delays in the python script to make sure the AVR can complete the command before the next one arrives. Apart from that, it all worked well when testing on an Alix or RaspberryPi. But i2c communication refused to work entirely when testing with the bifferboard. Not even i2cdetect could locate the device. That was bad, since I wanted to use it with the Bifferboard, and the other two were only for testing during the development. I checked with the oscilloscope, and found out that the i2c clock on the bifferboard runs with only 33kHz while the other two run at the standard 100kHz. So I tried to adjust the i2c clock settings on the AVR, as well as different options with the external oscillators and clock settings, but I was still still out of luck. Then I replaced the AtMega8 with an AtMega168 and it immediately worked. Next, I tried another AtMega8 and this one also worked with the Bifferboard. I switched back and forth and re-flashed them with the exact same settings. Still, one of them worked with all tested linux devices, while the other one still refused to work with the Bifferboard. So I concluded, one of these cheap AVR’s from china must be flaky, and I just used the other one. Seems like that’s what you get for one 6th of the price you pay for these chips in Switzerland.

Apart from the display, I also added an RGB LED that behaves like the BlinkM before. And on top of that a small piezo buzzer. But since I could hardly hear it’s sound when driven with 3.3V, I didn’t bother re-soldering it when it fell off.

Now, my co-workers also started logging their times with RFID.

The code is still on github.

switching the christmas tree online

The first time I got interested in home automation, was when browsing the arduino libraries. That was all about X10, which communicates over power lines. There are switches that can replace the regular light switches and are pretty cheap in the US. If you want such switches here in Switzerland, you’ll be surprised how expensive they are. And routers with X10 to make it accessible from your smart phone start at CHF 400. But what is easier to get here are the plugs with 433Mhz rf controllers. I got a set with one remote and three plugs for CHF 15 at hornbach. Then I ordered two different transmitters from China. One with the nRF905 chipset and an SPI interface. And one for sort of bit banging. I thought the one with SPI was going to be easier to use. I also found some code to interface it. But first I had to know what I need to send.

My first Idea was to use the DVB-T dongle with GnuRadio to sniff the rf protocol. Continue reading “switching the christmas tree online”

RaspberryPi reading analog input using an AtTiny through i2c

The raspberrypi has some GPIO (General Purpose Input Output) pins. That’s great for experimenting with electronics for example sensors and actuators. It’s totally different than an Arduino in many respects, but that’s something they have in common. Some of the pins have special functions. For example SPI, I2C, UART …

There is a breakboard adapter for all the GPIO pins with a ribbon cable that you can order from the US. That’s cool, but ordering stuff from abroad can be expensive. And the pins look somehow like good old IDE. So I soldered an adapter myself and bought an IDE cable. Well, some pins worked, and some didn’t… Enough for the first round of experimenting, but it took a while to find out what’s going on. I just assumed that all the wires of the IDE cable were connected which for some reason was not the case.

But something is missing that the arduino offers: analog. Before I really needed analog sensing capabilities, I found an article, describing a hack to read analog input by measuring the time it takes to discharge a capacitor through the resistance you want to measure. Immediately, I tried it myself with a photo resistor. The author warned, that the timings with the python script are not really accurate, and that the correct values for the components would have to be calculated. The Values I got were fluctuating wildly, and I couldn’t really see a difference with the brightness in all that noise.

So I looked for something more accurate. I still have some AtTiny’s and they have analog inputs. But SPI is the only means of communication they support in hardware. Last week, I implemented uart receiving capabilities in software, but this time I was looking for i2c. Continue reading “RaspberryPi reading analog input using an AtTiny through i2c”