- Punching at the Control Box
A control box is placed at the start and finish of the course and each each fox position. The competitor carries a iButton device contained in a key-fob. When the iButton makes momentary contact with a socket on the control box the real time is recorded on the iButton. The contents of the iButton are downloaded to a PC after the event and this enables the computer data to be used to to generate results lists, comparison run times and a multitude of other posibilities depending on the software.
I have tried to maintain the concept of ‘keep-it-simple’, but made variations to the original the design to provide a preferred solution for a given cost, availablity of component and hardware. Here is a quick run down of design choices.
Enclosure
- Along side a Commercial SI Unit
I have used a standard Hammond translucent box. Not the cheapest option, but to be honest, it was originally selected because it resembles the commercially available ‘Sportident’ (SI) control box, and was therefore more likely to be ‘acceptable’ to regular uses of the SI system !
However the box can be bought in bulk for a very reasonable price from Rapid Electonics. Like most ‘project boxes’ it has a screwed top – so the design incorporated a concealed latch switch behind a rubber ‘button’ to turn the unit on and off. Also, a countersunk screw is connected to the positive battery terminal so the battery voltage can to measured without having to remove the box lid.
footnote – the ABS material seems to be vulnerable to stress cracking around drilled holes. An identical sized box in polycarbonate material might be a better choice, but this has yet to be tried and tested.
iButton Socket
- 16mm Keyring Probe
I must give credit here to my wife, Elaine, for coming up with the idea, which resulted in using a standard keyring for the basis of the socket design. A 16mm keyring is a perfect fit for the iButton. The keyring needs to be expanded so its height is slightly above a centre contact pin. The photo shows the arrangement with the keyring soldered to a small piece of 25mm x 25mm pcb. The open frame of the socket means water is far less likely to be trapped inside the socket. Most important is the painting of the pcb and the lower portion of the keyring to minimize the possibility of rain water bridging the socket terminals.
footnote – the photo shows a round headed bolt, but this can put a dent in the face of the iButton with frequent use. Probably users are applying unnecessary excessive force when punching. I suggest changing the bolt for a flat head type.
Battery
PP3 were deemed far too expensive for this application ! An AA cell is used with a step-up regulator type NCP1400 and the cost of the regulator will be recouped with the first battery change.
The output rating of the NCP1400 is greatly reduced when using a single AA cell for 5v output, so as the NCP1402 is now readily available in the UK, that should be used in new designs.
Schematic
Below are links to my software code, originated by 9A5SP and modified by G3ZOI.
Please observe the request by 9A5SP to publish all improvements in accordance with the Artistic License 2.0
Please be aware this software is ‘work-in-progress’, but it has been used successfully on a number of RSBG ARDF events.
PIC Software for the fox location control box.
This is written in Mikroelektronika BASIC (free to use , with a very generous 2k program size limitation.)
In the ‘project settings’ :- use device = P16F628, Frequency = 4.194304 MHz
PIC software here.
MS Windows Software for the downloading from iButton.
This is written in Delphi. All library files are included. If you keep them together in one project folder. Delphi should run and compile the code without further configuration.
Dephi 6 & 7 should run under Windows Vista and above – just ignore the error dialogue messages when first loaded.
The current software version requires the ini file and the exe file to be in the same folder, then the output files are created in the same (event) folder.
The main source file is raydelun.pas.
The output files are
- [eventname].log – this is a compilation of individual competitor results, as they would appear on a printed results ticket.
- [eventname].kor – this is a ‘correction file’ which can be read by the FjwW program for results analysis and web publishing. (see below for examples)
The .pas file also has code (commented out) to output in OR format, but I regret I can’t remember how well that works !!!
MS Windows software here.
Examples of results using iButton, and then published using FjwW here.
happy punching !
Hi David.
Oporcon project looks really interesting. I will build one set of controls and buy some iButtons for competitors. We already got an idea to go away from “keep it simple” 🙂
What you think is it hard work to improve code of oporcon controller so it could send visited competitors as an APRS messages? By this we could get this more interesting for people in start/finish area. Sure it is not simple anymore when you need to leave APRS transmitter too the woods too.
73′ OH2JKU /Kimmo
@Kimmo: PIC 16F628 used in this design has a UART (serial) support. It isn’t hard to add additional code (there is enough free memory, and Mikroelektronika Basic makes this easy) to send informations about competitors via serial. As there are APRS transmitters which have support for serial communication with GPS receivers, it can be done (fairly) easily.
I’m thinking of coming back to my OPORCON this fall, to add such serial communication for usage with old GSM telephones and/or packet radio. I’ll look into APRS.
I agree that it should not be a big task for a programmer. I’m still not familiar enough with writing code. Originally I was thinking if such of APRS feature could be included for current 16F628 as for example tinytrak is done by PIC too. But sure getting serial output of visitors and send it out with other APRS device is also acceptable. We just did today first training event with Oporcons built last night. It was success story and we didn’t have any problems at all.
Maybe not possible for the same PIC because APRS/packet radio implementation takes so many outputs. But it might be okay solution to get Oporcon punches out as serial data and then send it with some serial capable device like aprs, packet radio or GPRS/3G/SMS.
Any idea why .kor file output are in wrong format?
Following test run 17:48 on 24.8.2012. I’m using win7 for reading results. Country settings Finland/Finnish, Clock 24h. Will try with uk country settings and report later.
@SAVE
@BEGIN-KOR
# — Start No.50 Fob No:50 —
254 50 :48:40 PM’00 8.24.22 0; 2; #begin
253 50 :48:34 PM’00 8.24.22 0; #start
65 50 :48:36 PM’00 8.24.22 0; #fox
69 50 :48:38 PM’00 8.24.22 0; #fox
248 50 :48:40 PM’00 8.24.22 0; #finish
Problem is related for country and regional settings. When changed country setting to UK instead of Finland then readings from oporcon are with 24h format. But when country setting is set to Finland then readings are in 12h format and output is messed up. Interesting because Finland is using 24h format for displaying time. Now I have a workaround, but maybe this is fixed in next releases. Thanks for the great sw, it’s very useful with FjwW.
# — Start No.50 Fob No:50 —
254 50 :48:40 PM’00 8.24.22 0; 2; #begin
253 50 :48:34 PM’00 8.24.22 0; #start
65 50 :48:36 PM’00 8.24.22 0; #fox
69 50 :48:38 PM’00 8.24.22 0; #fox
248 50 :48:40 PM’00 8.24.22 0; #finish
# — Start No.50 Fob No:50 —
254 50 17:48:40’00 24.08.12 0; 2; #begin
253 50 17:48:34’00 24.08.12 0; #start
65 50 17:48:36’00 24.08.12 0; #fox
69 50 17:48:38’00 24.08.12 0; #fox
248 50 17:48:40’00 24.08.12 0; #finish
Guys, a small update on : on my testboard I got David’s Oporcon working with complete bell’s and whistles (buzzer, dip switched control number selection) + added a serial communication which sends control number, timestamp and iButton identifier of last chip. So it’s possible, although I had to monkey around to get everything working (almost the same) as before.
To make it fit, some small changes done in code, which in return changed a little in function (small chirp of buzzer every 240 seconds). As I have to make new Oporcons from scratch, due to dead bug soldering of first version :D, complete info about this will come in a few weeks, after testing, partial info in a few days on my website.
As my minimalistic side changed schematic around buzzer (buzz is now in code), some small mod’s in code will be needed to fit this new software to David’s Oporcons, if anyone want’s to “upgrade”.
definetely will test it
I’m not sure if you already read my email about oporcon 1.5 testing. I did some tests and noticed some unstability. Sometimes sw seems to stop working. I don’t know why, but think it’s related for serial connection. However when sw is running it is working exactly like wanted. It will send needed information to the serial port. What I would like to change from code is to send information in decimal or string format instead of hex. Specially I would like to get time in more user friendly format instead of unix timestamp. I suggest that only fox id, hours, minutes, second and chip id is sent to serial port. That would be enough.
I don’t know why it stops, it should work. My Oporcons aren’t tested yet, so I’ll look into it.
Sending time in “readable” view can be done, although it’s not easy (but I’ll come back to it). Problem is representation of time – using 32 bit timestamp gives Oporcon an easy way out in terms of data storage. When I was developing first version of Oporcon there were several ideas: to use 1 byte to identify control, and 2 bytes for time in 12H format (similar to SI card 5). Then it was to use 1 byte to identify control, and 3 bytes for time (this would cover several months). Such system, which save both control ID and time, are 1/3 slower (at least) than current Oporcon system, because you need to read chip for the next free location, then write to it, then read it back to check if saved correctly. And you will need a box fo “CLEAR”, like SI has. When tried, that system didn’t work as good as I wanted, so full timestamp remained.
Why is 32 bit timestamp a problem? If you use 8 bit microcontroller, and you’re using 32 bit numbers, algorithms for some calculations are large. In MicroBasic there is a statistic for functions and in that you can see that David added simple “sec mod 60” to get a minute mark (and mod 300 for 5 minutes), and result was that it added more than 400 bytes of ROM code, because it had to work (divide) 32 bit numbers. 8 bit PIC isn’t equipped for that. It can be done better and in OPORCON1.5 you tested it really is optimized for some things. But even optimized it’s hard to fit algorithm for calculation of hours, minutes and seconds out of timestamp format.
Hard but not impossible. I have some ideas (and initial tests are promising), so be patient and your wish will come true 😀
I tested v1.6. Great job, It’s now stable and giving serial output. For some reason got few times 0000000000000000 as button information for serial output. Not often, but more than twice. Feeling it’s totally random when it’s happen.
logged few minutes
01,504F4E7D,17:45:17,F80000012E7B3108
01,504F4E7D,17:45:17,F80000012E7B3108
01,504F4E80,17:45:20,0000000000000000
01,504F4E81,17:45:21,F80000012E7B3108
01,504F4E82,17:45:22,F80000012E7B3108
01,504F4E82,17:45:22,F80000012E7B3108
01,504F4E83,17:45:23,F80000012E7B3108
01,504F5040,17:52:48,F80000012E7B3108
01,504F5078,17:53:44,F80000012E7B3108
01,504F5079,17:53:45,F80000012E7B3108
01,504F509B,17:54:19,F80000012E7B3108
01,504F509E,17:54:22,F80000012E7B3108
01,504F50A0,17:54:24,F80000012E7B3108
01,504F5155,17:57:25,F80000012E7B3108
01,504F51B0,17:58:56,0000000000000000
01,504F51B8,17:59:04,F80000012E7B3108
01,504F51C2,17:59:14,F80000012E7B3108
Hi Kimmo,
I agree with Stipe, using the UNIX time gives a nice simple and practical solution.
The windows software sometimes needs more than one attempt to read the ibutton, I put this down to my using a DS1402 probe, and therefore getting an occassional message conflict, but you may be right saying the software is a bit unstable, although it works well enough for me. Not sure I have the knowledge to fix the software at the communication level, at the moment !!!
Current Oporcon v1.5 solution is already ok. Thanks guys for great development. To be sure that I’m not misunderstood, asked modification is only for sending data out from serial port, no changes for the iButton write. But as it works today is totally acceptable and not mandatory to tune time display.
We just had an idea to sent competitors visits to the controller as live to the start and finnish area. Just simpy sending the info through packet radio or maybe just using cw. When receiving info to the “monitor/results” PC I just felt that if time is received in normal format then it’s easier to see and publish as a split time. Current solution means that HEX string is received and then someone needs to convert and publish it after conversion. Sure this can be done automatically in PC with own built software. But if there are no need for conversion then split times could be shown as it’s received for example in regular terminal program. I’m not a programmer so even small change seems to be hard for me. It might be that I’m asking something which is easier to do somewhere else. Mikrobasic library Time_epochToDate, can that be used or is that totally something else?
About oporcon v1.5 sw hanging, it will happen at least in my environment if there are any problems with serial port (ie. not connected or for example acidentaly pressed enter and sent data from pc to the line). Sure in real life data is not coming back so pressing enter should not be a problem.
David. No other problems with PC software than used country code affects for the output. Reading has been stable and also results has been correct.
I found scripts for pc which will do the job after small modifications. So I think we can keep time output as it is.
-Kimmo
Ahem, nice RS232 output is done. Some corners were cut as there is no enough ROM in 16F628 to do it right, but it should work without problems.
Everyone can download the new, highly experimental, version from my website.
Now to use the leftover 200 bytes and fit support for 16 char LCD display, and that would be it.
v1.6 working fine
David.
Maybe oftopic, but I’m asking it anyway. When using ibutton reader produced .kor files with fjww the file has control numbers from 65 to 69 in case of 5 foxes used. Are these numbers need to be set in fjww competition setup as a SI numbers? It looks like that what ever I have set for SI numbers in competition setup, I will always had correct results anyway.
The numbers 65 .. 69 are fixed correction codes in the Fjww software relating to TX-1 to TX-5. We are applying correction data here, rather than data as normally directly derived from the Fjww / SI reader. This method was originally proposed by Edwin Verburg PE5EDW, being the simpler solution – but not the ‘proper’ way !!
Thanks David, so correction will override values defined in fjww and those don’t need to worry at all. I was just confused of fjww usage.