StrobIt Board

Ok I have finally had a little bit of time to work on things (will be short lived as I’ve just bought a house and moving in the next couple of weeks Aghh!!).

Things are getting very close to reality after many design changes, the very nearly final Strobit Trigger base board, aka a modified Ardiuno BT board, with the Bluetooth removed and now fitted with the RFM12B SMD Tranceiver module and an external SMA antenna connector. The Eagle 3D side of things still needs work as some components are not shown and the inductor for the DC-DC converter is incorrect, but you get the basic idea right!

Why have I gone to a non-dedicated trigger board?

Well a couple of reasons, initially to cover myself from any patent issues that might have arrisen had I used a dedicated wireless triggering device, but mainly to allow better expandability. Why have a dedicated trigger with all the fruit and only use half of it, this way dedicated boards can be used, i.e. standard trigger, or sound/light trigger, sequences etc. Another reason is that the Ardruino is very well established and supported in the open source community, especially when it comes to the firmware libraries etc, it’s already been done. also I can use these in my robotics hobby as well, not just for photography.

Ok onto the board features:

  • Fairly compact same size as ArduinoBT
  • Standard Arduino Pin headers, so should be able to use with existing shields.
  • Will operate from as low as 1.2V, so should work from x1 NIMH AA easily enough.
  • RFM12 Tranceiver, up to 300m range (as per datasheets, although it does depend on the datarate)
  • SMA connector so you can connect an external antenna for better reliability and range, or remove the SMA connector and use a piece of wire as the antenna.

What is left to do?

  • Well the design is pretty well done, I want to get some prototypes made so I will be sending it off very shortly for fabrication.
  • Different variations of shields need to be done, first one being stock standard strobe type of triggr, input and outputs, then others as needed

StrobIt Triggr Update

I was surprised when I looked at my blog today how long ago my last post was, nearly a month ago…bugger where has the time gone – it’s nearly christmas again LOL!  Way overdue for an update I think.

Well I can tell you where the time has gone, mainly sourcing component suppliers and getting prices in for the Triggr boards, not to mention a redesign.

Have had a delay also with the design, which really was a lawyer thing.  After speaking with a few people and my laywer about some issues initially raised on the forums about the existing patent held by the Pocket Wizard People, I’ve decided to make some fairly significant changes to the design, All the functionality is still there and its still expandable, actually probably more expandable than it was before.  I just needed to make it a non-dedicated remote camera trigger, in fact it’s not really a trigger at all, confused? well all will be revealed 😉

In short these changes have been made but I need to finish the new PCB, which I’m hoping to finish this week, and then get some prototypes underway, hopefully I will get a 3-D model of it in it’s current form on this site as soon as I work out how to use Eagle 3D.

Most of the prices are in although I’ve not calculated the price based on the new design, it is still looking good, the biggest killer so far is freight.   When you can get resistors at $0.0016 each in reel of 4000, it doesn’t work out to be that expensive, however at freight of AUD$45+  it all starts adding up when you are needing different reels of capacitors resistors from different suppliers etc.  So…..at the moment in between finalizing the new Atmega Board design and my real day job, I’m sourcing a turnkey supplier and assembly so that I only need to pay freight once.

As a side note looks like best price breaks start at 1000 units for most things so I need to make sure I do my numbers correctly so I don’t end up with alot of expensive paperweights that I can’t get rid off LOL.

Trigger Fires Up

Well I finished the two prototype boards tonight with some minor changes and a bit of troubleshooting, still lots to do though.  I now have them triggering.  Will be testing further over the next few days to get indication of range etc.  So far it is only syncing at 1/100.  I will be posting more details , schematics, firmware etc as well as I get time.

Strobit Triggr fires up for first time

Strobit Triggr Prototype Finished

After a hectic and very hot Christmas (41DegC) I managed to get some development time and finished 2 prototype boards.  My RFM12 header boards still have not arrived, caught up in the christmas mail I guess 🙁  So I’ve had to resort to hand soldering some wires to the header in the meantime. (Murphys law suggests that as soon as I finish soldering these headers the breakout boards will arrive in the mail)

Tomorrow/Later tonight I will test both of them and see if I can get a remote trigger happening woohoo.

Sorry about the quality of the photos as they were taken with my phone 🙁

Strobit Triggr PrototypeRFM12 HeaderRFM12 Header SolderedRFM Development

SHT-15 Humidity Sensor

I couldn’t get any hands-on hardware development time for the Strobbit open triggr project today, so I designed a breakout board for the Sensirion SHT15 Humidity/Temperature sensor for my weather station I’ve been intending to build.  I have a couple of these sensors at home waiting for something this so I can have a play with them.  PCB uploaded for fabrication today.

As a side note:  While uploading this for fabrication at http://www.batchpcb.com  I noticed that my RFM12 PCBs has been panelized and so should be in production, hopefully they should rock up on the doorstep sometime soon.

SHT15 schematic

SHT-15 PCB

PIC, SPI and the RFM12

I finally had some time this weekend so I started the hardware verification, mainly getting the PIC and the RFM talking together via SPI, of which I have had no previous experience.  The PIC is receiving it’s clock source from the RFM12 via the CLK pin so I dont need any external Xtals.  The RFM12 default clock rate on reset is 1MHz, so the first challenge is to change the speed of the RFM12 CLK to 10MHz, that way I know the PIC and RFM12 are talking.

 As I’m doing most of my software development with BoostC (http://www.boostc.com), there is a library to use the on-chip MSSP (SPI and I2C) functions of the PIC16f873A, so I thought I’d use this and the on-board SPI functions to handle all SPI communications to the RFM12, after a very frustrating few hours and with my scope monitoring the SPI pins, I finally got the SPI to spit out proper CLK, SDO, and receiving something back on the SDI line after I realised I had not had my interrupts enabled to allow for the non blocking SPI functions DOH!

Now that something was getting out and back in, however none of the commands I sent seem to be getting through, well at least not interpreted as commands by the RFM12.  After much head scratching and re-reading of the RFM12 SPI timing diagrams It occurred to me that the 16bits that make up the the RFM12 commands were getting send through in byte sized chunks, i.e. 8 bits at a time were being sent through, then the next 8 bits were send with a delay in between the two bytes, this makes sense as the internal SPI uses an 8 bit register that gets transmitted, although the library I was using allows from the transmit of any number of bytes via a buffer.  I figured this was the problem and quickly wrote some bit banging SPI functions to test the theory, and straight away the RFM12 responded to my commands and now I have the PIC running at 10MHz.

So now that  all is working in the land of Oz as far as my PIC and RFM12 and talking to each other it’s onto finishing the RFM12 library I started last week and testing that with the RFM12 Demo board so I can test Tx and Rx functionality without having two development boards set up.

RFM12 Demo Board

Buzzbot – Odometry Task

Now that I have my Interrupts working on the the PIO Port, I have successfully adapted some code to provide Odometry for Buzzbot, based on reading the wheel encoders.    

This odometry task provides me with the following data:

  • Buzzbots Location in 2D Space (X and Y cooridinates).
  • Current Heading in Degees.
  • Average distance travelled in centimeters.
  • Angle of rotation about the axis.

I would like now to get the motor contol going, so at least I can get some basic movement, then the next step will then get some behaviour happening.    The PID combined with the odometry will allow me to command Buzzbot to drive to a specific X, Y Location, so I can do some calibration on the odometry to see how accurate it is.

All these tasks run under the FreeRTOS (http://www.freertos.org).