Author Topic: Designing a better RFM69 radio module  (Read 27102 times)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Designing a better RFM69 radio module
« Reply #15 on: June 08, 2016, 04:13:10 PM »
I've got one for ya, Felix.  How about you find a way to unequivocally encode whether the radio is HW or W!!!!   No more "I didn't know that I was supposed to uncomment that line..."

Tom
PS: I know this isn't an RF feature but it sure beats trying to get people to RTFM!

You bet.
Tom, I am sure you see this as often as I do and it's one of the most annoying things, both to the user and to us trying to help. Should have been a feature of the RFM module. I am thinking a new RFM module could sacrifice one of the less significant DIO pins (if the NC is used for something more important) to mark the difference between a W and HW. Boy would that solve a lot of issues.
In all honesty the RTFM in this case is really in the top 10-15 lines of settings and headers of any sketch, and it's commented with a !
How that is so hard eludes me. Anyway this is definitely on the must-do list of this module, whenever and if it will ever happen.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Designing a better RFM69 radio module
« Reply #16 on: June 08, 2016, 05:18:59 PM »
Why don't you just burn frequency and module type into flash with the bootloader. Then rfm69 could read these settings and it wouldn't be necessary to configure them. That would solve the problem until someone burns their own bootloader at which point they likely know what they're doing.

I mean why really should I have to tell a preassembled Moteino which components came with it.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Designing a better RFM69 radio module
« Reply #17 on: June 08, 2016, 06:36:33 PM »
Why don't you just burn frequency and module type into flash with the bootloader. Then rfm69 could read these settings and it wouldn't be necessary to configure them. That would solve the problem until someone burns their own bootloader at which point they likely know what they're doing.

I mean why really should I have to tell a preassembled Moteino which components came with it.
Hmmm, sounds like putting the cart before the horse.  The bootloader should be able to read the interface to determine whether its an HW, W, LoRa, and what frequency.  HOW that's done is interesting.  Sounds like an SC-70 serial rom on the radio module.  If this doesn't exist then I'll take credit for inventing it  8)

Looks like Microchip (and probably others) have beat me to it: 24AA01T-I/LT (1K bit in SC-70-5, 2x2mm, $0.19 each).

And, being I2C interface, I'll bet that the pins could be multiplexed with SPI pins so the ROM disappears after booting and configuration. 

Tom
« Last Edit: June 08, 2016, 06:55:05 PM by TomWS »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Designing a better RFM69 radio module
« Reply #18 on: June 09, 2016, 08:03:02 AM »
Quote
The bootloader should be able to read the interface to determine whether its an HW, W, LoRa, and what frequency.  HOW that's done is interesting.  Sounds like an SC-70 serial rom on the radio module.

In my setup I just flash all of that info plus aes key, uid, network etc into one flash page. Then the bootloader and applications can read the data from there. And since the bootloader is already capable of self-modification the gw can just send a patched bootloader with updated settings to a node if it wants to make modifications.

I'd be hesitant to add a component just for that functionality. But I'll admit being able to flash a different bootloader and still have the settings available in the external component is an advantage.

Joe

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Designing a better RFM69 radio module
« Reply #19 on: June 09, 2016, 08:47:22 AM »
Quote
The bootloader should be able to read the interface to determine whether its an HW, W, LoRa, and what frequency.  HOW that's done is interesting.  Sounds like an SC-70 serial rom on the radio module.

In my setup I just flash all of that info plus aes key, uid, network etc into one flash page. Then the bootloader and applications can read the data from there. And since the bootloader is already capable of self-modification the gw can just send a patched bootloader with updated settings to a node if it wants to make modifications.

I'd be hesitant to add a component just for that functionality. But I'll admit being able to flash a different bootloader and still have the settings available in the external component is an advantage.

Joe
It's more about having the module's parameters WITH the module.  Assuming the module was manufactured (ie, ROM programmed correctly) then ANY driver can read the data and correctly configure the radio. Without this 'someone' will have to put the parameters into the bootloader and we're back to the RTFM problem.

@felix, one comment made me wonder if you're thinking of having all of the SX123x signals fanned out to your modules pins.  I do not see the value in that.  Your value add would be making this module as small as possible fanning out ONLY the signals needed by a Moteino or Moteino-like design.

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Designing a better RFM69 radio module
« Reply #20 on: June 09, 2016, 08:58:00 AM »
It's more about having the module's parameters WITH the module.  Assuming the module was manufactured (ie, ROM programmed correctly) then ANY driver can read the data and correctly configure the radio. Without this 'someone' will have to put the parameters into the bootloader and we're back to the RTFM problem.

Absolute nobrainer there.

@felix, one comment made me wonder if you're thinking of having all of the SX123x signals fanned out to your modules pins.  I do not see the value in that.  Your value add would be making this module as small as possible fanning out ONLY the signals needed by a Moteino or Moteino-like design.

Tom

I started thinking more about that. What value do we have for all the GPIO anyway?
I think 2 PCB designs optimized for a W and/or HW would be an additional improvement.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Designing a better RFM69 radio module
« Reply #21 on: June 09, 2016, 10:47:55 AM »
I started thinking more about that. What value do we have for all the GPIO anyway?
There are a set of people who use those, especially the OOK crowd and I know that Joe has played around with them, but, from my perspective, this really is about getting the smallest radio possible - I'd pay extra for that.  Otherwise the HopeRF RFM69Cxx give me everything I need at an affordable price.
Quote
I think 2 PCB designs optimized for a W and/or HW would be an additional improvement.
That would be great for me, but may be overkill.  If you go IPD and just wire SPI & Interrupt (and add the EEPROM for identification) then you've got a winner in my book.  I think there is an advantage to having a single footprint - it allows upgrading a design that needs the higher power of an 'HW'.

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Designing a better RFM69 radio module
« Reply #22 on: June 09, 2016, 12:58:35 PM »
The PCB has to be well balanced and I still think compatibility is something to strongly consider. But that can be debated later.
Having made a batch of my experimental RFM69s, I learned a few things that I plan to apply in a future run.
One thing in particular is the components are quite different (W vs HW) and spotting any placement issues with 0402 components is very hard when there are blank pads around. I don't have an AOI so my eyes are the tool for that. The hope design is all-in-1 because on the W half the pads are unused.
I think a lot of complication is because of the RFswitch circuit and all the other components to support it, that introduces unnecessary 0ohm resistors in the W variant, to link the output path properly. Having 2 optimized designs would eliminate a lot of that noise BOM. The W would then be a lot easier to make, in the absence of a very good RF switch like the "G4C" which is not source-able in the USA.

RE IPD - doesn't look like there is one such device for the SX1231/h.
« Last Edit: June 09, 2016, 01:30:44 PM by Felix »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Designing a better RFM69 radio module
« Reply #23 on: June 09, 2016, 03:04:01 PM »
Quote
this really is about getting the smallest radio possible - I'd pay extra for that

Yeah the radio is the limiting piece at the moment in terms of size. For these super small applications you probably don't need the RF switch (+13dBm is sufficient for coin cells). Once one fixes the antennas it's amazing what you can get out of a rfm69w.

It might be worth making one that's usable with a cr1632 - soldered on of course, who has space for a battery holder  ;). The battery contacts would have to straddle the radio board.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Designing a better RFM69 radio module
« Reply #24 on: June 09, 2016, 05:34:10 PM »
For these super small applications you probably don't need the RF switch (+13dBm is sufficient for coin cells).
I agree with Joe on this one. 

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Designing a better RFM69 radio module
« Reply #25 on: June 10, 2016, 04:28:37 AM »
Quote
It might be worth making one that's usable with a cr1632 - soldered on of course, who has space for a battery holder  ;).

That would give you at most 15mm for the pcb: http://www.digikey.de/product-detail/en/panasonic-bsg/BR-1632-HFN/P299-ND/447507

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Designing a better RFM69 radio module
« Reply #26 on: June 10, 2016, 08:25:56 AM »
We have to realize if I try to make this, it's not going to be as easy as other things I assemble. I have to make lots to be able to sell them and eventually make a profit otherwise I'd rather use my very very limited time on other things. So lots of people have to like and want it and be willing to pay a higher price. It will be a hard sell if we niche this too much. In the end the economics plays a big role when making more than just a few units to play around at home. Hence some of the points I raised in my initial post.
A 13dBm design should be much easier to get started with.
IMHO the CW size 16x16mm is not too large.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Designing a better RFM69 radio module
« Reply #27 on: June 10, 2016, 08:50:25 AM »
IMHO the CW size 16x16mm is not too large.
IMNSHO a 13dBm radio could be done in a 10 pin 12x12mm package...

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Designing a better RFM69 radio module
« Reply #28 on: June 10, 2016, 12:47:38 PM »
Quote
IMNSHO a 13dBm radio could be done in a 10 pin 12x12mm package...

Just the right size for a CR1225  :D - 50mAh, but a least a new challenge.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Designing a better RFM69 radio module
« Reply #29 on: June 10, 2016, 11:00:20 PM »
You could also use the spare IO to manually over-drive the mux input of the RF switch (series resistor between the TXRX of the si1231h and the RF mux, brought out to the spare IO). You could then have full power range available by driving the IO pin to permanently select RFIO.

I understand the wiring of that, but I guess I'm not following how that would give access to the full power range? Which range are we talking about here, the TX power range?
Looking at the 20dBm schematic, my best guess is you mean that in TX we can override the RXTX pin to tun off the RFIO part maybe? That could be a very erroneous guess :P
But could you expand on that a little please? This could be an interesting development.

Basically yes (sorry for the delay in responding!). If the RXTX pin had a series resistor to the RF mux then this signal could be made available on the spare IO pin. This would allow the MCU to force the mux to always select the RFIO pin, that gives the same operation as a RFM69CW. Essentially the MCU will be able to overdrive it because of the resistor independent of the state of RXTX. If the MCU tri-states its driver (or is driven by a FET) then the RXTX takes over, so then you have RFM69HW operation. In theory the MCU can select the entire TX power range.
Mark.
« Last Edit: June 10, 2016, 11:09:08 PM by perky »