SMIRF timing in the configuration mode

Wireless & IoT
1

Hi Guys

I’m debugging a code to program the smirf in a selected channel in the lowest time as possible. First. I program the smirf with big delays and then I decrease the delays for example from 50 to 1 ms. Then If I turned off the smirf and power on again the minimiun delays don’t work. I have to put the 50 ms delays to work again.

What is the problem??

Thanks

2

Hi Jean,

Sorry for the lack of replies. We’ve been spending all of our energy on a new SMiRF firmware. Once we get it rolled out - we can sit down and test the VB interface.

-Nathan

3

When do you think the firmware will be ready??

4

We are in the process of re-programming units today. I will try to get Pete to post a link to the new HEX file tomorrow.

-Nathan

5

hi nathan

can you tell me the improvements in the new firmware? which issues have benn resolved??

Thanks

6

Howdy!

Here’s the link to the new code:

http://www.sparkfun.com/datasheets/Serial-RF-v25.zip

What we did:

We started by getting rid of a bunch of firmware handshaking between the SMiRF’s. The nRF2401A’s (the RF chips from Nordic that the SMiRF’s use) have built in addressing and CRC. We now use their system alone for error checking, and it’s made the code a LOT faster.

Without our extra error checking, we were then able to trim our packet size a bit and cut down our timing margins. That equates to more data transmitted in less time.

Then we started experimenting with address length, finally settling on 16 bits as a good compromise between speed and accuracy.

The “scan button” also got a retrofit. Now when you press it momentarily, the address and channel each advance by one. And when you press and hold the button for more than 2 seconds it resets the unit to channel 20, address 20 and 9600 baud. This should make initial setup as painless as possible.

The end result is that we have great data throughput. 9600 and 19200 bps work great and have no more issues with buffer overrun. 38400 even works well, but we may be losing every twentieth line (give or take - it may also be a hyperterminal glitch, hard to tell when it scrolls by that fast).

Something worth noting is that the new units and the old units aren’t firmware compatible. The ones with the older revision can be upgraded, though, either by us or the user.

Hope you guys like the new code.

Pete

7

Hi Nathan

Did you remember a I had one unit which never Iget to reprogram, now I have to 2 units with the same problem. I tried to reprogram the smirf with the new hex file but the winpic programmer cannot program farther than 23 bytes.

I downloaded the winpic800 software to program the pic16f688 but I can not get to work the pic. I got the same problem . it can program just 24 bytes.

I dont know how you reprogram the units. I put cables and check the connections but I can not find the real problem.

Please send me the configuration for the winpic hardware. and what can I do. .

Another strange thing is if I put a dip pic16f688 chip . I can be programmed 100%.

Thanks

8

Hi Jean Paul,

It must be a problem with your programmer trying to do ICSP. You’ll need a powered programmer.

We received your 6 units and sucessfully reprogrammed all of them.

-Nathan

9

Hi Nathan

Today I test my remote units and only 2 units worked well. the other 2 units didn’t work. what can I do???. I can enter to the smirf menu but when the smirf exit and i send 1 byte the led turned on for 1 time and then nothing!!. in the terminal I received the character 0x20. The problem I dont know if it is the pic or another chip. and I supose all the chips were ok. so ?? what can I do?