Thursday, July 30, 2009

Updated RFM12B-USB Interface

After review of the first RFM12B-USB interfacing, I noted that I'm driving the RFM12B over the design spec wrt the power supply. RFM12B is designed for 3.6V max VCC whereas USB supply typically is near 5V. As such, I've redesigned the interface to be 5V friendly with on-board 3.3V regulator and voltage dividers on the signal lines.

This board is double sided but does not need plated through holes as no top side soldering required on the components (except for vias). There is a technique on how to do that with Eagle which I may cover in next postings...

Monday, July 27, 2009

Over the weekend... RFM12B-USB Interface & CNC Work...

Had some spare time over the weekend so I decided to move on on my wireless data logger project. The slave/master communication was ironed out earlier. At least I know that data are being transmitted and received correctly because the checksum is valid. I had no way of knowing what actual data was transmitted because I had no visibility on the communication.

So, I decided to make a small RFM12B-to-USB interface as shown below. With this unit, I should be able to sniff the communication over the air and display the capture information on a PC. Yet to do some codings for it though, for the PIC and the PC. Not only the interface allows me to sniff the traffic, I can actually make it behave either as slave or master. That will be helpful in testing the configuration and logging protocol later on.

I also spend few minutes on my Sherline CNC to mill out some holes for a friend. He wanted to mount the digital volt and ammeter to the casing... so my CNC was summoned to the rescue... In photo below, the meters have not been flush mounted to the casing... once flushed mounted, it's gonna be pain in the *&^ trying to take it out because of the very tight fit...

Friday, July 17, 2009

Checked your VISA statement lately...?

NEW YORK (CNN) -- A technical snafu left some Visa prepaid cardholders stunned and horrified Monday to see a $23,148,855,308,184,500 charge on their statements.

Josh Muszynski noticed the 17-digit charge while making a routine balance inquiry.

That's about 2,007 times the size of the USA national debt.

Josh Muszynski, 22, of Manchester, New Hampshire, was one Visa customer aghast to find the 17-digit charge on his bill. Adding insult to injury, he had also been hit with a $15 overdraft fee.

He noticed that his debt exceeded the world GDP while making a routine balance inquiry on his online Bank of America account. According to his statement, he had spent the profound sum in one pop at a nearby Mobil gas station -- his regular stop for Camel cigarettes.

"Very, very panicked," he jumped in his car and sped to the station.

Full story here...

Wednesday, July 15, 2009

Farnell Did It Again...

As mentioned in my previous blog, I bought a tube of 22 pcs of PIC16F690 for less than RM85. As I indicated, PIC16F690 has very similar functionality with PIC16F88. However, the price was 75% cheaper than PIC16F88 (RM85/22 vs RM336/25). Well, Farnell revised the price today to RM242 for tube of 22. Previously, I also bought a tube of 25pcs of PIC16F88 for RM150 and a week later, Farnell revised it to the current price of RM336 for 25pcs. Hmmm... maybe I should have kept my mouth shut...

Moral of the story... if you see something really cheap at Farnell, it probably is. So, if you want it, buy it quick... before they revise the price upward...

The enclosure for datalogger

The enclosure above, with access panel for 2 x AAA battery, will be used for the datalogger. Photo posted for 9w2dtr for the PCB design reference... :-)

Friday, July 10, 2009

Creative Problem Solving

In trying to figure out the best protocol for my wireless multinode data logger, I needed a way to visualise the problem. For those interested, here's the problem statement... simplified to everyday scenario... :-)

A sales department has a BOSS and 16 STAFF


  • BOSS wants sales update every 1 day.
  • STAFF should MAXIMISE time outside of office.
  • Staff updates can be done inside the office only.
  • No way to contact STAFF once they are outside of office.
  • The BOSS and staff do not use watches. They only have timer/stopwatch (95% accuracy) thus statement "Update me at 3.30pm" cannot be used, but "Update me 30 minutes from now" is acceptable and the timing may be off by 5%.
  • Only 1 party (BOSS or STAFF) talk at any given time.
  • The updating only takes 2 minutes!
  • BOSS and STAFF works 24-hours per day.

Find the most effective way (scheduling or otherwise) to get sales update on time and maximise STAFF time doing sales.

Thursday, July 9, 2009

Update: Cytron UIC00A Limitations

Further to my earlier blog that I was having problem to program PIC16F88 when MCLR is disabled and using internal clock as system clock, I just come across the following note added to the (new?) UIC00A User Manual from Cytron. Please take note of the limitations. BTW, the PIC is not spoiled.

RFM12B+PIC: Let's sleep... separately....

As typically done, to conserve power, electronic devices are put into a 'sleep' mode. For the RFM+PIC setup I had mentioned previously, the same method is employed. The PIC commands the RFM to go into sleep mode but preprogrammed the RFM to wake up in about 5s... very very short nap... after the RFM is commanded to sleep, PIC commanded itself to sleep indefinitely until awaken by something...

After the 5s nap, RFM will wake up (5% accuracy) and will pull the nIRQ line low. The nIRQ line is connected to one of PIC 'interrupt-on-change' pin. The change in voltage level wakes up the PIC and it will continue to execute exactly where it falls asleep.

Wednesday, July 8, 2009

RFM Slave Testing Units

In order to test RF module to module communications, I needed simple boards that could easily be made and programmed. Also, considering the future use for the module, I needed to find a suitable PIC microcontroller to do the job... Final selection was PIC16F690... it has all the bells and whistles, seemed to be as powerful as PIC16F88, but surprisingly 75% cheaper. Not sure if this is another Farnell incorrect pricing but I've gotten myself a tube of 22... :-)

Initial test has been completed, after the addition of more white hairs to my head. The module could send and receive packets correctly. I'm now focusing on how to minimise power consumption as we wanted the module/PIC to run for about 6-months with a simple AA (or AAA) batteries. Once that is solved, I'll move on to developing suitable protocol for master/slave monitoring requirement.