RADIOHEAD - Questions about versions, beginTransaction, multiple buss

Status
Not open for further replies.
KurtE

KurtE

Senior Member+
I am playing around with of the Adafruit RFM95 LoRa Radio boards, that I am planning to use with some Teensy in my well monitoring system. I also have a couple of the Feather M0 with These radios also...

Following Adafruit's instructions they have you download V1.59 of the Radiohead library. Also I know that Teensyduino installs a copy of RADIOHEAD, which I believe is about version 1.24. Looks like the current version is 1.61

So my first question to myself is which version should I use?

The one thing that the version that Paul's version has, is an "ugly hack" to enable SPI transactions.
Code: 
// Ugly hack for testing SPI.beginTransaction...
#if (RH_PLATFORM == RH_PLATFORM_ARDUINO) && defined(SPI_HAS_TRANSACTION)
#undef ATOMIC_BLOCK_START
#undef ATOMIC_BLOCK_END
#define ATOMIC_BLOCK_START SPI.beginTransaction(_spi._settings)
#define ATOMIC_BLOCK_END   SPI.endTransaction()
#endif

I assume I can obviously duplicate this hack into the later versions.

However I was also thinking about trying to see how hard it would be to allow me to maybe move the radio to SPI1 (TLC and beta T3.6) or SPI2 (T3.6)... WIll probably follow up on this part on Beta thread.

My thoughts are to duplicate the RHHardwareSPI.h/cpp and these versions have SPI1 or 2 in them.
Already the constructor for the Radio class allows you to pass in your own SPI class:
Code: 
 RH_RF95(uint8_t slaveSelectPin = SS, uint8_t interruptPin = 2, RHGenericSPI& spi = hardware_spi);
So it should just work...

However the Ugly hack as it is won't work properly as again it assumes SPI. I was thinking of changing the Generic SPI class to maybe have Block Start / Block End members, which hopefully the different implementations can do the right thing.

Does this make sense?

I forked a copy of Paul's library, but I am thinking of updating the code here to the latest and trying it out.

I also wonder if the library developer is interested in making it work with transactions or not?

Thoughts?
 
Side note:
Wonder if this is still needed?
Code: 
void RHHardwareSPI::begin() 
{
    // Sigh: there are no common symbols for some of these SPI options across all platforms
#if (RH_PLATFORM == RH_PLATFORM_ARDUINO) || (RH_PLATFORM == RH_PLATFORM_UNO32) || (RH_PLATFORM == RH_PLATFORM_CHIPKIT_CORE)
    uint8_t dataMode;
    if (_dataMode == DataMode0)
	dataMode = SPI_MODE0;
    else if (_dataMode == DataMode1)
	dataMode = SPI_MODE1;
    else if (_dataMode == DataMode2)
	dataMode = SPI_MODE2;
    else if (_dataMode == DataMode3)
	dataMode = SPI_MODE3;
    else
	dataMode = SPI_MODE0;
#if (RH_PLATFORM == RH_PLATFORM_ARDUINO) && defined(__arm__) && defined(CORE_TEENSY)
    // Temporary work-around due to problem where avr_emulation.h does not work properly for the setDataMode() cal
    SPCR &= ~SPI_MODE_MASK;
#else
 #if (RH_PLATFORM == RH_PLATFORM_ARDUINO) && defined (__arm__) && defined(ARDUINO_ARCH_SAMD)
    // Zero requires begin() before anything else :-)
    SPI.begin();
 #endif

    SPI.setDataMode(dataMode);
#endif
...
 
I concluded I was too dumb to use radio head. So I wrote my own system with the help of easy transfer.

However, underlying it all is that the s1 version of Xbee which allows Serial in = Serial out. It's transparent, makes your teensy think it's attached with wires. Even enables RTS and CTS. The OEM also sells a longer range 900MHz version.

I happily paid for the more expensive hardware solution to save a few more of my remaining hairs on my head. Picking battles and all that. For the more experienced programmers the documentation included with radio head may make great sense. As a novice, I found it less than helpful.
 
Last edited:
Thanks Constantin,

I have used S1 XBees in the past, although I have never tried their 900mhz versions. They might be a good match for my project, but I will play around with these radios. Hopefully it should not be too difficult to figure out.

Note: In the past with XBees I ended up switching to packet mode as I was wanting to send logical packets anyway and that way the XBees took care of things like checking for valid packets, including checksums for me. Likewise I could receive confirmations back that the packets were received...

Also again it is probably not an issue for this project, but with some of my robotics projects, I was running into issues with using XBees bidirectionally, that there may be relatively long periods of time when the xbees would stop talking... But I hear you that hooking up TX/RX pins can be a lot easier than figuring out how to get it working on SPI, especially if you have other SPI devices as well.

Kurt
 
I have been playing around some more today and have a version of the Radiohead library, where I think I went through and added a beginTransaction/endTransaction set of calls around all of the places that appear to output stuff to the radios.

I started some testing today with this and as I mentioned in first thread, first RFM95 breakout board blue smoked when I plugged it in. It looks like the VR is fried... Not sure if Adafruit will cover it or not, but appears to be dead short between VIN/GND...

However I was able to connect the 2nd one up to T3.2 and I can use it to talk to the two Feather boards with the same radio.

So I first tried, the Simple RX/TX examples that are part under the Radiohead library. At first the radio on the Teensy did nothing, but found I needed to set the IO pin to high that I have connected to RST pin. With that it initialized. I then installed the other program on one of the Feathers and it is partially working.

That is every second the feather sends a message (broadcast) which the Teensy receives and prints on the display, The teensy tries to send a message back to the other side. I know the message is at least making it to the RFM05 as it goes into wait for send to complete, which only happens when the RFM95 completes the message and then sets the interrupt pin... However the Other side is not seeing the data.

So I tried loading up the program that was on Teensy onto the other feather and it is also behaving the same.

But then I loaded up the Reliable network versions of the software and then the two feathers talk both ways. so will try again probably in the morning on the Teensy... Then I may for the fun of it see if I can actually get it to talk using SPI1... And maybe then move TO T3.6...

I will look more at the SPI communications probably later tomorrow when I have faster logic analyzer...

Kurt
 
Good to hear about SPI progress or at least a good test setup for RFM95 to get there, sad to hear it leaked the smoke.
 
Also interested in this because Lora testing is one of the next things on my to do tinker list :) .
 
Thanks defragster,

Yes making some progress, still wondering why the simple datagram is failing one direction. I do notice there are some places i the code that have Teensy 3.1/2 hacks to maybe add time delays in or the like. So not sure if there are some race conditions or maybe some radios need a slightly longer time between when the processor raises or lowers CS...

As per Adafruit support: I posted about the smoke, including a picture that showed the fried VR up on their forum, and this morning received a reply about getting a replacement module.
Edit: Adafruit support was quick and replacement part will be shipped

Epyon: I have also been thinking of tinkering with these for awhile as I have run into issues with XBees in the past where bidirectional communications can cause long unpredictable times when no messages are received... And I know a few others with same issues have had some good success with some of these other radios. So thought I would give them a try.
 
Last edited:
As I mentioned in the RFM69 thread... I have had some luck now with the the simple test, by adding in a short delay after it receives a message and before it tries to send a response. However for me, I will probably go with the higher level protocol anyway.

If anyone is interested in my WIP with adding SPI Transaction support into the current RADIOHEAD version of the library, I pushed up a new branch of my fork of Paul's version up at: https://github.com/KurtE/RadioHead/tree/SPI-Transaction-Support

Next up, see if with this I can add an SPI1 version (copy SPI implementation at lower level), pass in pointer to this into constructor to object...
 
Another quick update.

I made a duplicate of the underlying HardwareSPI support in RadioHead and updated it for SPI1.

I then first verified I could run with normal SPI and then tried on SPI1.... More on the beta thread.

I pushed the changes up to my fork/branch
 
Kurt, Do you have any links to your fork? I am just now working with the RFM95 version of the LoRa boards from Adafruit on a Teensy 3.6, and would like to run them on SPI1 instead of SPI0. I tried modifying the Radiohead RHSPIDriver, and just wound up screwing it up. I have the chip select on pin 25, Interrupt on 35, Reset on 24. Any help you can offer would be wonderful. Thanks!
 
Status
Not open for further replies.
Back
Top