Hardware

Strobit Wireless Widget

Wireless Widget

Widget Mesh

Rallylog

Makecontroller

CNC

Picaxe

CAD

Eagle3D Parts

Well there aren’t really any downloads for this projects just yet.

However for the prototype based on the PIC16F88:

• Drawings are available here

• BoostC source code and Eagle files are here .

If you have any questions please contact me via the contact form.

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.
  Update: 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

During the development of the StrobIt Open Trigger Project I’ve been using the HopeRF RFM12B Tranceiver as the RF module. The learning curve was fairly steep so I’ve decided to create a series of How-To articles so that others can easily get the module up and running fairly quickly for their project of choice. So far I’ve already slated these for use in a few other projects around the house, both robotics, home control and weather station related.

(more…)

Introduction

20/03/09 *UPDATE * This project now has a new home and is actively being developed on Google code project hosting http://code.google.com/p/strobit/

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 – http://code.google.com/p/strobit/

Still Todo:

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

License

The strobit hardware design is covered by The TAPR Open Hardware License. Please see http://www.tapr.org/ohl.html for further details.

Schematics:

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.

I’m pleased to announce the very ALPHA release of the RFM12 library for the wireless HopeRF RFM12 FSK tranceiver module that I’m using for the strobist open trigger project.  It was developed under BOOSTC for the PIC embedded controller, but should be easily ported to any compiler.

Most of it is untested, hence the alpha release, but it’s a good starting point.  Everything is fairly well documented, but like any project could do with more.   Please send me any bug fixes/improvements that you may find while using it.

Download:  rfm12-0_1a.zip 

Features:

• 433Mhz and 915Mhz HopeRF FSK RFM12 modules supported
• Initialisation with a basic config
• Set Frequency
• Set Receiver Bandwidth
• Set Receiver Gain
• Set Receiver Signal Strength Indicator Level (RSSI)
• Set Transmit Power level
• Set Transmit Modulation
• Set Baud rate
• Enable/Disable Transmitter
• Enable/Disable Receiver
• Transmit a single byte – blocking
• Transmit a buffer of data – blocking
• Receive single byte – blocking with timeout
• Receive ‘x’ number of bytes into buffer – blocking with timout

 TODO:  (not in any order)

• Testing
• Howto documentation
• RFM12 Interrupt handling 
• Non-blocking Tx/Rx routines
• MSSP SPI implementation (current SPI implemented via bit bang)
• Frequency hopping
• Custom configurations

License:

Released under the Creative Commons – Attribution-Noncommercial-Share Alike

Disclaimer:

Please use this library at your own risk.  I will not be held liable for any damages.

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.

Trying to fit the functionality into the existing ebay trigger receiver housing seems to be a royal pain in the butt, especially trying to work in with the batteries, so after a few days of PCB redesigns and juggling compments around I have put that particular design on hold and moved forward with my original PIC16F873A design, also I did not like the fact that there was 2 circuits to maintain, a transmitter and receiver, this then leads me to the next problem.  I want something easy for the end user, something similar to the Pocket Wizard Plus that is really a no brainer for the user to drive, i.e. a switch to select operation mode and channels, a 3 and 4 way slide switch respectivly, well do you think I can source any 4 way slide switches easily?  Seems I can get some 3 way easily enough, and I guess I could use a rotary switch but these are too clunky for my liking, but still an option.

(more…)

A couple of design changes,  main one being I could not physically fit a single design into the existing housings that would encompass the Tx and RX, the RX housing is the problem as it’s a fairly small board so that means I’ve had to change the processor so that I can physically fit everything as well as the RF onto the board, so now a single design using the PIC 16F873A now becomes 2 circuits, Tx and Rx using a PIC16F88 as the MPU.

(more…)

Well it’s certianly been a long since my last post, sorry!  Between getting married and christmas (all on the same day lol), and the kids going back to school, my geeking (as my wife likes to call it) has been taking a back seat lately i.e. not a whole lot happening.  However I have managed to squeeze in bit of learning.  The first getting myself familiarilised with PIC micros, the picaxe although brilliant for small jobs, I have found to be limited, i.e. no timers etc.  so I have been playing around with their big brothers.  The fist learning project was a serial LCD using the 16F84,  I’m using the brilliant Sourceboost BoostC Compiler ( http://www.sourceboost.com/ ) 

Also came across a brilliant DSP guide in an easy to understand language and not heaps  if heavy maths , and its FREE for the online book http://www.dspguide.com/, this really made the light go on, ding! with the Ahh I get it in the smoke and mirrors world of DSP.    I’m definately looking at purchasing a hard cover version.

My PICAXE Projects

• BuzzBot Blog – A R/C Toy being converted to a robot using the PICAXE
• LED Switch – Interesting Sensor Concept using an LED as both a Light Emmiting Device and as a Light Sensor

I came across an interesting article yesterday on Hack-A-Day about using a LED as a Photo Sensor and cheap communictaion device.  This is achieved by using some physical properties of the LED for both Transmit and Receive.  The article also links to a cool video clip demonstrating this. Original Article can be found here http://www.hackaday.com/entry/1234000873073550/

Anyway this sparked my interest and I soon had a PICAXE-08M hooked up to test if it-in fact it works (I also made sure that the date was not 1st April LOL).  After about an hour I had it working, this code requires 3 LEDs, One acts as the Light Source and is always on (not really necessary, you can use anything as a light source, the brighter the better), the Second LED acts as the Sensor and is connected to two outputs along with the current limiting resistor, this is really the heart of the concept.  The third LED is a status Indicator and gets switched on and off depending on the reading of the LED Sensor.  

This idea, as simple as it is, makes for some interesting sensor ideas.

Here’s the PICAXE code - LEDSwitch.zip

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

Issues 

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.

Conclusion 

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.

Last night I did some brain storming asto what the I/O requirements will be.  During this requirements phase I came across a bit of a delima with the PWM requirements for the motor controller.  The motor controller requires two outputs per motor, so this rules out using the onboard PWMout command of the PICAXE, as there are only two dedicated PWM pins on the chip that I’m using.  Although I could do it with some additional glue logic in hardware, I don’t really want to do that (as I’m lazy), so now I will be doing it all within the software, this should free up the servo command within the PICAXE, so I can now use this to drive the servo for the sonar unit.

I’m going to be using the PICAXE 28X. With my I/O current configuration of the 22 available I/O on chip, I have 2 Inputs/Outputs and 4 Analogue Inputs Available for future expansion (or and additional 4 inputs if I don’t want to use the analogue inputs).  It will be interesting to see if the processor will be fast enough process everything in a timely manner, especially with the motor control and encoders.  Well I guess I’m about to find out.

I’m now going to actually get my hands dirty with the PICAXE as I still haven’t plugged the development board into my PC yet

BuzzBot – I/O Requirements

Buzzbot – PICAXE Circuit

Ok encoders are in, although not wired up.  So I quickly re-assembled the wheels and motor controller board for a quick test.  Glad to say that everything tested aok.  Put my logic pulser on the inputs and sure enough forward and reverse is easily attained on both motors, although due to the low frequency pulses of my logic pulser the motor speed did hunt a little.  Now reassembling with cabling to go to my pic development board.