tht / t3libs Goto Github PK

Just got a Teensy 3 and a RFM12B-S2 from Sparkfun, wired it up according to the diagram you provided, loaded the sketch, and... nothing. Any ideas? I tried changing uart the serial to see if that was the issue but still no dice.

The CS line goes high too quickly during an SPI transfer on my Teensy 3. This prevents the RFM12B from operating normally. Here's a screenshot of logic analyzer output from an OLS. (Ignore channels 5-7, any 'signals' on those are crosstalk because I left them disconnected)

This is the second SPI transfer (the 0xB800 data was a debug attempt, based on what the RFM driver in Jeelib does). The first transfer (0x0000) to get the status is fine, but the other transfers exhibit essentially the same timing. As you can see, the CS line goes high before the transfer is complete. This occurs 660ns after CS goes low and 200ns after the first bit is started. The T3 is running at 24MHz for this sample.

It would appear that, for some reason, the SPI0_TCR register is incrementing before the SPI transfer is complete. I've verified as best I can (print statement) that the CTCNT bit is getting set in the SPI0_PUSHR register, which should prevent this. I wonder if the TCR register is incrementing after transfer to the buffer for some reason?

For now, I've added 'delayMicroseconds(50)' right after while '(! SPI0_TCR)' in the rf12_xfer function. This resolves the timing issue and permits the RFM12B to operate normally, at least with the provided demo sketch. From the OLS output, 50us is probably a bit long, it's just what I started with. It looks like a delay of 5us, or maybe less, should work.

The only other thing I've done with this T3 is use the FastSPI library. Not sure if that could result in a setting that causes the issue. Since the EEPROM is erased each time the T3 is programmed, this doesn't seem that likely, but you never know.

Just so it's documented, I'm using Arduino 1.0.3 w/Teensyduino 1.12 on Ubuntu 12.04 (64 bit) as my dev environment.

I have OLS client files with and without the added 50us delay. I'd upload them here, but github didn't like that, let me know if you'd like copies. If I can help debug this further, I'm glad to do so.

The driver reports back all received packets, even if they are addressed to another node.
=> Should only report packets sent to broadcast or own node id

Note: allows to abort reception as soon as header arrived.

The integrated hardware CRC unit is much faster than the current software implementation. Try to move to this one.

recvDone() returns always true when there was something received, even if CRC is invalid.
=> Make configurable.

There has to be an easier way to check packet length than RF12->buffer[0];

Same with header, data und CRC from received messages.

Starting a transmit just overwrites the internal state without checking the current state. This may completely kill the program flow.

Currently the data rate is fixed to about 4.8kbps. This is not the same as JeeNodes use which makes it harder to use.

Data rate should be configurable.

Currently ARSSI has to be connected to A0. Note everyone needs ARSSI values and what about people using A0 for something else?

Port should be configurable, deactivating should be possible.

What about calculating dBm out of the current mV?