• Performance improvements and Prototype Boards

    Will • 04/28/2014 at 11:19 • 0 comments

    I've spent a bit of time in the past few weeks optimising and improving performance. For the Arduino expansion boards I've been able to increase the maximum sampling rate by around 40%. I'm slowly doing more work to reduce the amount of serial traffic required as this appears to be the major bottleneck. 

    On the hardware front, my prototype RaspberryPi DAQ boards arrived from OSHPark as did all my components, however... DISASTER! Somehow I've got the wrong footprint on the RaspberryPi header. The pin pitch is too small. 

    I'd normally consider building one anyway for testing purposes and just using wires to connect the board to the Pi but given the ADC is fairly expensive I don't think I'll do this just yet. In the meantime I'm going to have to do a bit of investigation into why my footprint was wrong. 

  • Slow progress... software updates

    Will • 04/16/2014 at 14:08 • 0 comments

    Progess this week

    I was pretty excited to see Blitz go up on the Hackaday front page, that was pretty cool! Thanks to those of you who followed and skulled.

    I've been distracted this week preparing my dissertation for printing (tomorrow!), as a result there hasn't been a lot of progress. The main changes I made to the software were related to the way the "server" acquires data. Originally I envisaged just a USART connection, however for my dissertation I needed to add support for a custom ethernet pressure sensing device and now I'm looking at SPI for higher data acquisition rates. 

    These bits of software all do the same task of tasking data from a sensor (expansion board) and writing it to the server's database in the correct format, yet they are all written in separate classes with no common inheritance. As a result, I'm really not happy with the state of it at the moment. I've started to pull out common functionality into a "ServerPlugin" class that will allow different adapters (ethernet, USART, SPI, etc) to be loaded when the program is run. These will work in a similar way to the expansion board plugins on the client side which autoload when the program starts. That way you can connect all sorts of devices and Blitz should automatically find them for you as it currently does for USART devices. There is still a way to go here but the first steps have been made on the dev branch. 

    I also implemented a basic Raspberry Pi digital GPIO acquisition system although I haven't got around to testing this yet. 

    Finally I've started to work on the project documentation. I'm using a custom Python static site builder I wrote to create the documentation from Markdown. You can see the WIP documentation on the project links on the left hand side. My supervisor needs this so he can operate the DAQ in the wind tunnel after I graduate :) 

    How its been used so far

    Here is what my set up looked like in the wind tunnel at uni:

    My laptop top right was acting as client and server, and the little car shaped "bluff body" you can see in the wind tunnel working section had a moveable aerodynamic diffuser which I can actuate from the software. The little silver boxes you can see in the top middle are the ethernet pressure sensor I'm using to read from pressure tappings on the bottom of the bluff body.

  • [Weekend Project] Raspberry Pi Shield

    Will • 04/06/2014 at 22:47 • 0 comments

    This weekend I decided to have a break from study and spent a couple of days designing a SMT Raspberry Pi Shield for the Blitz DAQ.  The board uses the Raspberry Pi GPIO pins and provides a 4 channel 15-bit ADC as well as 5 digital inputs (the Blitz DAQ message format allows five digital flags). 

    With this shield you could remove the need for a separate Arduino and avoid the issues with Raspberry Pi GPIO on a non-realtime operation system. By using SPI for the Raspberry Pi to shield communications I'll also be able to bump the sample rate up from the Arduino / USART based configuration I've mostly been testing with.

    I've got some input protection on the analogue pins - basically Zeners and PTC fuses and I'm trying to work out if I should put a buffer/follower in as well. I don't know any hard and fast rules about when this might be a good or bad idea.

    I'm comfortable enough with the design that I feel I could build a prototype, however I'm just heading into my last six weeks of Uni so it will probably be a little while before get around to it!


    P.S. like the Blitz DAQ software, this and the firmware will be released as open hardware when I'm happy.

  • Released as Open Source, Future Plans

    Will • 04/03/2014 at 23:12 • 0 comments

    Open Source

    I always planned to release the software as open source, but wanted to wait until it was minimally functional. I reached this point a couple of weeks ago so now the project is released into the wild! There isn't much documentation yet but I'm currently writing the manual that should provide enough information to get going. Its about 80% done so the plan is to finish it over the Easter break and upload it to Github.

    Future Plans

    Even though my dissertation is all written up and only a few weeks away from handing in, I plan to keep working on the software. I want to implement a lot of the interesting features that weren't needed by the University but I think would really make the data acquisition system awesome for hackers and makers. You can see some of the plans in the github issues list as well as in the README.