Preliminary RF Tests

Today I did some testing on the RF side of things,  nothing scientific, just walking around the house seeing if it would dropout or report bad checksums, I’m happy to reports all is working as expected (using the 915Mhz RFM12B module)

The tests are done by using the RFM12B Example sketch found in the JeeLab RFM12B library by Jean-Claude over at Jeelab (RFM12B Arduino Library)

This library runs unmodified on the wireless widget board, just follow the instructions in the README about setting up node ids.

From the preliminary testing using some compact 1/2 wave GSM 900MHZ/1800MHZ antennas (  I’m easily getting all the way around the house with no dropouts, have yet to do outside tests.

Step 2

Convert POV file into Eagle3D .inc file

  1. In the new POV file that was created by the plug-in now needs to be saved as a *.inc in the same directory as Eagle3D component include files this is usually called EAgle3D\pov


  2. Next we need to delete all the information not needed and will cause conflicts with Eagle3D.
       1: // Persistence Of Vision raytracer version 3.5 (or higher) file.
       2: // Exported from Sketchup 6.4.112 (en-US) through SU2POV 3.2. by D. Bur.
       3: // 04/03/2009, 16:25
       4: //-------------------------------------------
       7: // Pov-Ray includes
       8: #include ""
       9: #include ""
      10: #include ""
      11: #include ""
      12: #include ""
      13: #include ""
      14: #include ""
      15: #include ""
      16: #include ""
      17: #include ""
      18: #include ""
      19: #include ""
      20: #include ""
      21: #include ""
      22: #include ""
      23: //-------------------------------------------
      26: // Declare section
      27: //Gamma
      28: #declare GAMMA=2;
      29: //Default finish
      30: #default { texture { finish { ambient 0.1 diffuse 0.7 brilliance 0 roughness 0.005 } } }
      31: // Finishes
      32: #declare Dull = finish {specular 0.5 roughness 0.2}
      33: #declare Shiny = finish {specular 1 roughness 0.0003}
      34: #declare Glossy = finish {specular 1 roughness 0.0003 reflection 0.1}
      35: #declare Phong_Glossy = finish {phong 10 phong_size 300 reflection 0.1}
      36: #declare Phong_Dull = finish {phong 0.5  phong_size 1}
      37: #declare Luminous = finish {ambient 0  diffuse 20}
      38: #declare Mirror = finish {ambient 0  diffuse 0 reflection 0.97}
      39: // Lights colors
      40: #declare Incandescence = rgb <1, 0.9, 0.6>;
      41: #declare Halogen = rgb <1, 0.98, 0.85>;
      42: #declare Sodium = rgb <1, 0.6, 0.2>;
      43: #declare Neon = rgb <0.9, 0.95, 1>;
      44: #declare Mercury = rgb <0.92, 1, 0.92>;
      46: #declare Lightbulb = sphere {
      47:     <0,0,0>,1.5
      48:     scale <1,1.3,1>
      49:     texture { pigment {color rgb <1, 1, 0.5>}}
      50:     finish { Luminous }
      51:     }
      53: //-------------------------------------------
      56: //Radiosity settings
      57: global_settings {
      58: radiosity { Rad_Settings(Radiosity_Final, off, on) }
      59: assumed_gamma GAMMA
      60: radiosity { gray_threshold 0.8 }
      61: }
      62: //-------------------------------------------
      65: // Gradient Background
      66: sky_sphere {
      67:     pigment {
      68:     gradient y
      69:    color_map {
      70:     [(1-cos(radians(0)))/2 color White]
      71:     [(1-cos(radians(50)))/2 color rgb <0.741176470588235,0.819607843137255,0.815686274509804>]
      72:     }
      73:     scale 1
      74:     translate -1
      75:     }
      76: }
      77: //-------------------------------------------
      80: //-------------------------------------------
      83: //-------------------------------------------
      86: // Camera
      87: camera {
      88:     perspective
      89:     location <2.25145468567195,1.60043897233161,-1.06394822934727>
      90:     look_at <-0.466904134380124,-0.965594533672687,1.31022929677542>
      91:     right <1.3333,0,0>
      92:     up <-0.436428953203423,0.815008198675065,0.381171096619603>
      93:     angle 63.7985225255377
      94: }
      95: //-------------------------------------------
      98: //-------------------------------------------
  3. Copy and paste the following code into the very beginning of the file.  replace ‘inc_MRF24J40MA’ with the name of your component, e.g. inc_YOUR_COMPONENT.
    #declare inc_MRF24J40MA=true;
    #declare inc_testmode=true;
    #include ""
    #undef inc_testmode
  4. Now scroll down until you see the start of the object definition
       2: // LEVEL 0 #<Sketchup::ComponentDefinition:0x3e508c0> MRF24J40MA
       3: #declare MRFceJeaMA = union {
       4: mesh2 {
       5:     vertex_vectors {
       6:       4,
       7: <7.000109088,4.98688000008518e-006,1.35>,
       8: <7.000109088,0.32000498688,1>,
  5. insert the component macro declare statement (line2 below) into the file.  The macro name needs to be the name of your component (in this case ‘MRF24J40MA’)
       1: // LEVEL 0 #<Sketchup::ComponentDefinition:0x3e4f8b8> MRF24J40MA
       2: #macro  MRF24J40MA()
       4: #declare MRFceJeaMA = union {
  6. Scroll to the very end of the file and delete lines 3,4 and 8 as shown below
       1: //-------------------------------------------
       3: #declare MODEL = union {
       4: } // End of MODEL object declare
       5: //-------------------------------------------
       8: object { MODEL }
       9: //-------------------------------------------
      12: #object {MRFceJeaMA
      13: matrix < 0.1,0.0,0.0,
      14: 0.0,0.1,0.0,
      15: 0.0,0.0,0.1,
      16: 0.0,0.0,0.0>
      17: }
      18: //-------------------------------------------
      21: //-------------------------------------------
  7. Finally insert all of the following to the very end of the file.  Replace MR24J40MA() with your component macro name.
    #end //end of macro  
    //Size of the Grid Plane (+/- span)
    #local XYZ_span=20;
    //Orientation axes
    cylinder{<-XYZ_span,0,0><XYZ_span,0,0>0.1 pigment{Blue}}    //X
    cylinder{<0,-XYZ_span,0><0,XYZ_span,0>0.1 pigment{Red}}        //Y
    cylinder{<0,0,-XYZ_span><0,0,XYZ_span>0.1 pigment{Yellow}}    //Z
    // Useful GRIDS:
    #local XYZ_step= 1 ;          // axis increment
    #local XYZ_cnt = 0;           //  loop counter
    #local xyz_thick = 0.05;     // grid line thickness
    // GRID PLANES: Remove comment begin/end to activate & select PLANES:
    #while (XYZ_cnt <= XYZ_span)
        cylinder{<-XYZ_span,0,XYZ_cnt><XYZ_span,0,XYZ_cnt>xyz_thick pigment{Blue}}        // Positive Z-Lines
        cylinder{<-XYZ_span,0,-XYZ_cnt><XYZ_span,0,-XYZ_cnt>xyz_thick pigment{Blue}}    // Negative Z-Lines
        //cylinder{<0,XYZ_cnt,-XYZ_span><0,XYZ_cnt,XYZ_span>xyz_thick pigment{Red}}        // Positive Y-Z Plane Lines
        //cylinder{<0,-XYZ_cnt,-XYZ_span><0,-XYZ_cnt,XYZ_span>xyz_thick pigment{Red}}    // Negative Y-Z Plane Lines
        //cylinder{<-XYZ_span,XYZ_cnt,0><XYZ_span,XYZ_cnt,0>xyz_thick pigment{Red}}        // Positive Y-X Plane Lines
        //cylinder{<-XYZ_span,-XYZ_cnt,0><XYZ_span,-XYZ_cnt,0>xyz_thick pigment{Red}}    // Negative Y-X Plane Lines
        cylinder{<XYZ_cnt,0,-XYZ_span><XYZ_cnt,0,XYZ_span>xyz_thick pigment{Yellow}}    // Positive X-Lines
        cylinder{<-XYZ_cnt,0,-XYZ_span><-XYZ_cnt,0,XYZ_span>xyz_thick pigment{Yellow}}    // Negative X-Lines
        #local XYZ_cnt = XYZ_cnt+XYZ_step;
        #local tt = 40;                //let's you change the distance easily
        location <-tt,tt,-tt>
        //location<0,5,-50>            //alternate location
        look_at <0,0,0>                //best to select the approximate centre of the object
        angle 30
    light_source { <100, 100, -100> White}
    light_source { <-100, 100, -100> White }
    light_source { <-100, 100, 100> White }
    light_source { <100, 100, 100> White }
    //light_source { <-tt,tt,-tt> White }
    //light_source { <-tt,tt,-tt> White }
    //light_source { <-tt,tt,-tt> White }
    //End of Macros
  8. Now test the inc file by rendering the component.  This will test to make sure the macro and file are all working.  A grid and the actual component will now be rendered.image
  9. UPDATE: You also need to copy any surface map graphic files across to the same directory as the new component file.

If you have successfully converted the file we next need to add it to Eagle3D

<<Step 1 Step 3 >>


Here’s are some initial non scientific test results of the prototype.

Sidenote: I had some fun testing these outside at night, everytime a car drove past I triggered the strobe, instant brake lights, hehe (The use of speed cameras are notorious here in Western Australia).

The Unit, both the master and slave are identical, personality is determined at powerup by pressing the trigger button if you want a master.

Test Rig of slave mounted on a strobe.

Running at 12500bps, camera syncs to 1/125 ~60m

running at 9600bps, camera syncs to 1/100 ~120m


Prototype boards RF module Testing

Prototype Specs:

  • PIC16F88 running on internal 8MHz Clock – low cost and very popular, free development tools available, i.e. C compiler.
  • Works in unlicensed 915MHz ISM Band(Australia/US), can work at 433Mhz by changing RF module(US/EU/Australia).
  • RF uses FSK Modulation – Less prone to interference sources.
  • All aspects of the RF module is configurable via the firmware, i.e. frequency, Tx power, receiver bandwidth, modulation, datarate etc.
  • Indoor Range – ~30m+ works all through my house non line of sight, i.e. through multiple single brick walls, with transmitter at furtherest end, close to AV, TV & WIFI (i.e. interference sources) and receiver roaming throughout the house in different rooms, microwave oven also in the mix. No packets lost or dropped so far, but more testing needing to be done.
  • Outdoor Range – Untested, but from indoor tests I would guess 150-250m easily.
    Outdoor Test Results here
  • Antenna – Simple 8cm whip (i.e. a single piece of wire), these RF units are matched to 50Ohm so an SMA antenna could be used
  • Sync to 1/125 – in theory it could easily sync upto 1/1000 as the Rf modules are capable of the bitrate necessary, however range will be affected by the higher the speed, also the processor / oscillator arrangement may need to be revised to handle the higher interrupt rate to process data, i.e may need to use a chip with onboard SPI support etc.
  • Can act as Master or Slave.
  • Can be programmed to use any frequency from 902Mhz to 928Mhz (using the 915Mhz module), using the 433Mhz Module will allow similar channels.
  • Can be triggered by a contact closure on Trigger Input. i.e. from camera
  • Can be manually triggered by test button.
  • Trigger output is isolated upto 400V, i.e. can safely trigger old stobe units with high voltage on hotshoe / sync terminals
  • Powered by x3 AA batteries. Currently no power management in the firmware.
  • Cost per prototype board AUD$ ~25

Note on the costs:

  • Most components are sourced via local retail outlets so are probably definately more expensive that sourcing elsewhere, i.e. this can be built a lot cheaper i.e. Sub $10 in parts.
  • Some of the components I had lying around at home so I’ve just used market prices in my estimates.
  • No freight was added to construction costs.
  • Some components have minimium order quanties such as the RF module.

Back – Triggr Home Next – Firmware

StrobIt Triggr


20/03/09 *UPDATE * This project now has a new home and is actively being developed on Google code project hosting

IMPORTANT    This page is no longer being being maintained please go to the new project page.

Welcome to the Strobit Triggr Project, an open source hackable wireless trigger used in photography lighting by using low cost strobe units triggered remotely via RF. This was started while trying to find a cost effective and reliable solution to the commercial alternatives out there. At one end of the market is the Ebay or Cactus Trigger, which is low cost but rather unreliable. At the other end of the market there is the industry standard, Pocket Wizards, very reliable, but very expensive (i.e. way out of my price range).

What I wanted to do was to create an open platform that anyone can easily build for a low cost and then be expand upon by the community. The pair of prototypes I’ve built were a proof of concept that I can get a camera to trigger a strobe unit reliably at a low cost. From early tests it appears that I’ve succeeded in my goal, but further testing is required.


Project Status :

– Prototype successfully working in single master/slave configuration !

– (20/03/2009) Project now has a home at Google Code –

Still Todo:

  • Specifications
  • Hardware Design
    • Schematics
    • PCB
  • Software Design
    • Wireless
    • User Interface
    • Protocol
  • Hardware Prototype


The strobit hardware design is covered by The TAPR Open Hardware License. Please see for further details.


Strobit Triggr Block Diagram Strobit Triggr Topology StrobIt Triggr Schematic

Prototype Details

Firmware Description

Protocol Description

Downloads – Files associated with the project

Tests – Tests done so Far

In the Wild – Version of this trigger made by others

I’m toying with the idea of putting together a low cost kit for the enthusiast. i.e. PCB, pre-programmed PIC, etc. So we could all benefit with a bulk order of the components. If your interested please email me using the contact form the top menu or use the mailing list signup on the right to give me an indication of numbers interested. Once I finaliaze the design and get some idea of numbers I’ll get a better idea of price. At the moment it will only be available in kit form due to FCC and other Licensing regulations.

Future Improvements:

  • Higher Sync Speed.
  • Frequency Hopping.
  • Forward Error Correction.
  • Power management.
  • UI to change settings, Channel etc.
  • Save settings in Flash memory.

BuzzBot – Initial Testing

I started testing last night after finishing initial motor and wheel sensor hookups to my development board.  Couple of minor issues so far. 


I’m using a pic based board from Modtronics. These are great and reasonably priced, along with the prototyping daughterboard.  However I have since found that the onboard RS232 is not on the same pin as the PICAXE28X, so I had to wire in an additional programming circuit, no biggy.  The other issues so far were the wheel sensors.  From my initial design I had used 10K resistors to bias the output of the opto-transistor, this was not tested and when testing the logic probe was picking things up ok, but not the PICAXE, after much stuffing around and not being able to find my multimeter (it was still packed away from shifting house) I ended up prototyping the same circuit, still had some issues, so I went  hunting for my multimeter and of course it was on the bottom box lol.  Luckily thanks to my trusty multimeter I found that the sensor was just dropping down to 3.8v when interrupted, anyway the solution to the problem was a larger resistor, a 22K on the output, this tested AOK, now getting ttl levels when switched, I also noted that the distance of the sensor to the reflective object (paper in this case) was fairly critical.  I modded the breadboard and then found one side was working fine, the other was not being seen.  Checked and found that the sensor was slightly further away than the one that was working.  So out with the hot glue gun and moved the sensor.  Both side are now giving me a reading on the PICAXE.

Motor Tests 

Next I adapted some motor control routines on Hippys PICAXE site to test my motor circuit.  First I tested without my motor control board plugged in, didnt’ want any smoke to escape, and all logic tested aok, then came big crunch of running motors live.  I can gladly say that all tests worked A1 with no issues.  Motor was tested though a range of 3 speeds in FWD, REV, Turn right FWD , Turn Left FWD, Turn Right Rev, Turn Left Rev, Spin Left and finally Spin Right.  While Testing the FWD and REV, I checked the Pulses from the wheel encoders to see how much the same each drive was over 100 counts from the wheel encoders and it looks like the Right side is slightly stronger than the left, no real surprise here as no two motor/gearbox combinations are the same.  I had thought about this a few days ago and knew that with any differential drive system I will encounter this type of problem.

Motor Control Algorithm 

This then leads me onto my motor control algorithm.  Over the last few days I have been researching PID Controller and their application to motor control for robots, as I want Buzzbot to drive in a straight line, also been looking at fuzzy logic, but I think will give that a miss at the moment.  I have been thinking of using and adaptation of the PI Proportional controller from the book “Robots – Inspiration to Implementation”  however so far I’m not 100% happy with the PWM and the way it is from the code I adapted, while it is very simple and works,  I would really like to use the onboard PWMout routines, but as I mentioned in an earlier entry it is only limited to two PWM and to two physical pins on the PICAXE – Bummer!!!!   I also thought I can use the old PWM command.  This command requires it to be refreshed, much like what is happening in  my test code, except with a agreater resolution, unlike the PWMOUT that runs in the background, perfect I thought!, but when I went to test it I found it’s only available on the 08 series…double Bummer!!!!!  So now may have to look at teh PulseOut command.

While the existing configuration does give me three speeds, the lowest is time critical and I notice that when I add a debug routine the slowest speed does start pulsing, also I don’t think it will give me the fine control needed on each of the wheel speed controllers.  I’m going to have to think about this a bit deeper.


All in all everything is working as expected, with a couple of minor hicups along the way.  Biggest issue will be PWM resolution and time of my routines.  I think I’ll need to come up with another way of doing what I want simply and without too much additional hardware if I want a closed loop control system.  While I ponder on this I’ll test the IR Sensor circuits.  These I’ll prototype first before I hardwire in.  Once I finish these I can then start working on behaviour.  I would like to look at using some sort of subsumption model, but will look at it deeper as I get closer.

buzzbot -  Motor Testingbuzzbot -  Motor TestingBuzzBot - Modtronics PIC Board

Buzzbot – Wheel Encoders

Now that the Motor Drive Controller has been worked out, (but yet untested)  I needed to make up some encoders for the Left and right Wheels.  After a bit of research I found an excellent program for creating encoders and quickly made two and have just glued them to the inside of the wheels for some rough and ready testing.  I really think I will need to make them more durable, but for the time being they should surfice.  Once I have the encoders and the sensors mounted I will start some testing on the drive system and the PicAxe.

Some quick calculations to see what I get:


 Wheel Diameter (D)=50mm
 wheel Circumference (C)= D * 3.14 = 157mm
 Encoder Resolution (Res)= 16

 Distance Travelled Per between encoder Pulses =  C/Res = 9.81mm

So per encoder output pulse width = 4.9mm (~5mm) – Remember the encoder has a resolution of 16 (50% black and 50% white) therefore I need to divide by 50% to get the per pulse distance assuming a nice neat square wave.

I’ve also placed the encoders in the top cover, filed out some slots and hotglued to suit. 

 BuzzBot Encoder Template Buzzbot Wheel encoders Buzzbot Encoder Sensor Placement