Hey guys,
people often claim that it's impossible to tell the HW apart from the W in software. That always seemed extremely unlikely to me given that there are clearly different physical processes involved. So for the fun of it I just tried identifying one. Took exactly 10 minutes to get right:
#include <RFM69.h>
RFM69 radio;
void setup()
{
Serial.begin( 500000);
}
void loop()
{
radio.initialize( RF69_868MHZ, 1, 10 );
uint8_t tempw = radio.readTemperature();
radio.setHighPower( false );
radio.setMode( RF69_MODE_TX );
delay( 500 );
radio.setMode( RF69_MODE_STANDBY );
tempw = radio.readTemperature() - tempw;
delay( 500 );
uint8_t temphw = radio.readTemperature();
radio.setHighPower( true );
radio.setMode( RF69_MODE_TX );
delay( 500 );
radio.setMode( RF69_MODE_STANDBY );
temphw = radio.readTemperature() - temphw;
Serial.print( "This is a RFM69" );
Serial.println( temphw > tempw ? "HW" : "W" );
delay( 2000 );
}
I tested it at 868 mhz but can't imagine this doesn't work at the other frequencies as well.
Joe
If this really works consistently, that's awesome!
This protocol could be run once in the lifetime of the mote, bit saved to EEPROM.
How would you do this on a coin cell mote though? Blast it at full power?
QuoteHow would you do this on a coin cell mote though? Blast it at full power?
The code below runs the radio at -1 dBm where it draws 16mA according to spec. It identifies the chip reliably for me. Probably still needs some massaging to get right for all cases - but you get the picture.
Joe
#include <RFM69.h>
#include <RFM69registers.h>
RFM69 radio;
void setup()
{
Serial.begin( 500000);
}
uint16_t readTemp( uint8_t count )
{
uint16_t ret = 0;
while( count-- ) ret += radio.readTemperature();
return ret;
}
void setHW( bool isHW )
{
int8_t powerLevel = -2;
uint8_t paSetting;
uint8_t pwl18 = powerLevel + 18;
if (isHW) {
if( powerLevel <= 13 ) // 0 - 13: -2 - +13, formula -18 + pwr
paSetting = RF_PALEVEL_PA1_ON | pwl18;
else // 14-20: +5 - +20, formula -11 + pwr
paSetting = RF_PALEVEL_PA1_ON | RF_PALEVEL_PA2_ON |
( 11 + powerLevel );
}
else paSetting = RF_PALEVEL_PA0_ON | pwl18;
radio.writeReg( REG_PALEVEL, paSetting );
radio.setHighPowerRegs( isHW );
}
void loop()
{
radio.initialize( RF69_868MHZ, 1, 10 );
radio.setPowerLevel( 0 );
int16_t tempw = readTemp( 100 );
setHW( false );
radio.setMode( RF69_MODE_TX );
delay( 3000 );
radio.setMode( RF69_MODE_STANDBY );
tempw = readTemp( 100 ) - tempw;
delay( 5000 );
int16_t temphw = readTemp( 100 );
setHW( true );
radio.setMode( RF69_MODE_TX );
delay( 3000 );
radio.setMode( RF69_MODE_STANDBY );
temphw = readTemp( 100 ) - temphw;
Serial.print( "This is a RFM69" );
Serial.println( temphw - tempw > 20 ? "HW" : "W" );
delay( 5000 );
}
Good job, Joe!
One step closer to the Nifty-Thing!
Tom
Great stuff, thanks joe!
BTW one caveat I see is this assumes a well matched antenna.
QuoteBTW one caveat I see is this assumes a well matched antenna.
Interestingly exactly the opposite of what I had expected to happen happened here: like you, I would have assumed that a real antenna would radiate more power, leaving less reflected to heat up the chip. That was the original idea.
However the chip with connected antenna heats up MORE. Don't ask me why ;)
Joe
Maybe I haven't thought that one through, I will have to try it on a Moteino but this may behave different on different boards.
Would the ultimate test be to leave the ANT completely unconnected? Or just test the code with various terminations to see if the results are at least consistent or behave wildly?
Quote from: joelucid on April 04, 2017, 04:15:24 PM
Interestingly exactly the opposite of what I had expected to happen happened here: like you, I would have assumed that a real antenna would radiate more power, leaving less reflected to heat up the chip. That was the original idea.
However the chip with connected antenna heats up MORE. Don't ask me why ;)
Joe
If it was a well matched antenna it should represent a 50ohm load.
Tom
QuoteIf it was a well matched antenna it should represent a 50ohm load.
Right. I just know from my module heating experiments that the modules get hot much quicker if you don't have an antenna connected than if you do. Maybe you need at least the matching components to generate the heat? Such that a completely open port would just have an unlimited impedance and allow no current to flow?
Joe
And if that's right it should work even without antenna and there's a much better test for coin cells utilizing the internal resistance of the cell: just measuring vcc during tx in both conditions would give you an immediate response. So the overall test could first probe using battery internal resistance and if that's not conclusive do the more power hungry temperature test.
Quote from: joelucid on April 05, 2017, 02:10:27 AM
Such that a completely open port would just have an unlimited impedance and allow no current to flow?
Yes, that's what I was thinking although I didn't complete the thought... :-[
Re Coin Cell, I wouldn't think that test would even be necessary. I can't imagine combining a coin cell power source with an HW radio (unless there was a pretty HUGE bulk cap).
Tom
QuoteYes, that's what I was thinking although I didn't complete the thought... :-[
That was a good point though and potentially the key to the general solution!
QuoteRe Coin Cell, I wouldn't think that test would even be necessary. I can't imagine combining a coin cell power source with an HW radio (unless there was a pretty HUGE bulk cap).
It doesn't make sense to use them for the larger tx power capability, but some people standardize on the HW - given that you can use it down to 1.8V @ 16mA at -2 dBm they work fine with coins. I still have a couple such beasts.
Plus I bet Felix will not touch anything that doesn't solve all setups :)
Joe
I think the HCW will be the way to go in general. That's not to say that a coin cell should use that, I would opt for the CW for that.
The W/HW format is unnecessarily large and complicates matters for me.
I am optimizing to support the HCW/CW on all motes (except a coin cell mote which will only support the CW). It will take a while. There is now the R5 which takes the HCW footprint only, the next revision will take both HCW/CW.
RE the heat test, if this is to be bootstrapped, i think it should work across all motes, with any antenna or without, and with any battery or power option. Otherwise we either have different pieces of code depending on hardware configuration, and then it's more complicated than just using the #IS_RFM69HW and it obsoletes this method.
IOW this code has to just work regardless of anything.
But I believe that short of having a hardware indicator, this is a very good solution. The only better thing than this is having a logic pin on the RFM69 itself. That's another discussion perhaps - but my thought on that is that we know that the HCW/LoRa footprint will always take a 20dBm radio, whereas the CW footprint will be a 13dBm or a RFM12B. So.. the Moteino itself could implement this on its own - it could be as easy as a solder jumper - the only problem is it would still require user intervention.
Quote from: Felix on April 05, 2017, 08:23:46 AM
The only better thing than this is having a logic pin on the RFM69 itself.
WHAT A GREAT IDEA! Whatcha think, Joe?
;D
Quote from: Felix on April 05, 2017, 08:23:46 AM
The only better thing than this is having a logic pin on the RFM69 itself. That's another discussion perhaps - but my thought on that is that we know that the HCW/LoRa footprint will always take a 20dBm radio, whereas the CW footprint will be a 13dBm or a RFM12B. So.. the Moteino itself could implement this on its own - it could be as easy as a solder jumper - the only problem is it would still require user intervention.
It'll only require user intervention if the user is fitting the components though, and they are likely to be more savvy. The link approach would allow you to actually sell W or HW parts knowing that the firmware would need no modification. You could make the decision on whether it's worth that depending on volumes and demand.
ISTM that the firmware would need a bit of rationalisation, the only parameter to the set power method would be the power level, -18 to +20, and if it knows the harware type it could set a mode based on the lowest power configuration for that requested power such that the registers are configured accordingly in operation (i.e PA0 only, PA1 only, PA1+PA2 and PA1+PA2+HP). Some data from this post might be handy:
https://andrehessling.de/2015/02/07/figuring-out-the-power-level-settings-of-hoperfs-rfm69-hwhcw-modules/
Mark.
QuoteWHAT A GREAT IDEA! Whatcha think, Joe?
;D
;) - yeah, well. If someone does it for me great. If not I'm sure I'll mix up radio modules just as I occasionally burn the wrong bootloader. The cw/hcw help here. Plus what to do with the installed base?
I typically don't even encounter these issues since my bootloader knows the chip and the app can get the setting from the bootloader. But I've been working a bit wihout it and now I regularly waste time with the wrong hw settings.
So - I've tested this with and without antenna. Works great. I've refined it a little - it now takes less than 1s in total and blasts in a frequency area that's likely to have little antenna efficiency to avoid disturbing the environment too much.
My bet is the coin cell compatible detection via VCC impact will also work but I haven't had the time to do it.
I've added this to my library and at least for any setting where there's any doubt about which radio will be used I'll use auto-detect from now on. Here's the implementation. it uses my library but should be readily translatable to RFM69 - at least if Felix adds a more flexible setPowerLevel.
int16_t SX1231Driver::getTempRise( bool hw )
{
uint32_t f = getFrequency();
if( f > 450000000UL ) setFrequency( 433000000UL );
else setFrequency( 868000000UL );
int8_t pwr = _powerLevel;
bool wasHW = _isHW;
_isHW = hw;
_powerLevel = 0;
setPowerLeveldBm( 13 );
setMode( SX1231_OPMODE_STANDBY );
delaySteps( ROUGH_MILLIS_TO_STEPS( 100 ) );
int16_t t1 = readTempRegSum( 10 );
setMode( SX1231_OPMODE_TRANSMITTER );
delaySteps( ROUGH_MILLIS_TO_STEPS( 300 ) );
setMode( SX1231_OPMODE_STANDBY );
int16_t t2 = readTempRegSum( 10 );
_isHW = wasHW;
_powerLevel = 0;
setPowerLeveldBm( pwr );
setFrequency( f );
return t1 - t2;
}
bool SX1231Driver::detectHW()
{
bool HW = getTempRise( true ) > getTempRise( false );
delaySteps( ROUGH_MILLIS_TO_STEPS( 100 ) );
logValue( LOG_HW, HW );
return HW;
}
Joe
Too bad that I'm currently busy with other stuff, because here's the next idea how to use this approach:
We know that a bad antenna (for example none) behind a matching network generates the most heat since most energy gets dissipated in the matching network. A good antenna generates less heat since a lot of energy is radiated away. In other words the quality of the antenna match can directly be measured via the temp increase during tx.
I think this is pretty valuable and goes beyond what you measure with a VNA since it excludes the energy initially reflected by the antenna which gets reflected a second time at the radio and makes it into the antenna on the second attempt.
Of course it won't measure the dissipation loss in the antenna - so WhiteHare's resistor "antenna" will look perfect. But it could be used to optimally size and manipulate the typical l/4 antenna. And to compare the efficiency of different antenna styles.
Joe
Quote from: joelucid on April 06, 2017, 03:27:01 AM
We know that a bad antenna (for example none) behind a matching network generates the most heat since most energy gets dissipated in the matching network. A good antenna generates less heat since a lot of energy is radiated away. In other words the quality of the antenna match can directly be measured via the temp increase during tx.
I think this is pretty valuable and goes beyond what you measure with a VNA since it excludes the energy initially reflected by the antenna which gets reflected a second time at the radio and makes it into the antenna on the second attempt.
Speaking as one of the many without any decent measurement tools for dialing in antenna length empirically, this sounds very promising! In addition, I wonder whether wrapping the Moteino in insulation would amplify the thermal heating even more, thereby improving the effective measurement resolution? [Edit: Of course, for testing purposes only!]
Could we not simplify this topic just saying that only RFM69HW or now RFM69HCW are recommended (even if RFM69CW is supported; powers from -18dBm to -2dBm are probably useless)
So, no jumper, transceiver standardisation, parts management improvement, configuration flexibility...
Defining the 4 modes or operation in the library
(Mode 0 from -18dBm to +13dBm (or max 45mA) -if necessary but depreciate option in case of RFM69CW usage :P)
Mode 1 from -2dBm to +13dBm (or max 45mA) - Default mode equivalent to RFM69W or RFM69CW
Mode 2 from +2dBm to +17dBm (or max 95mA)
Mode 3 from +5dBm to +20dBm (or max 130mA
No mention of the setHighpower function anymore , but (setPowerMode0), setPowerMode1, setPowerMode2, setPowerMode3, with a granularity of 16 possible values using the setPowerLevel function.
Robert
Seems like a function like Joe uses would be better i.e. specify dbm and let the function choose PA0, PA1, and PA2 to accomplish the broadcast power using the least mA.
When I run the sketch posted by joelucid in the very first message in this thread after entering the correct frequency I get the following error:
RFM69_LowPowerLab/RFM69.h:232:18: error: 'virtual void RFM69::setMode(uint8_t)' is protected
virtual void setMode(uint8_t mode);
^
sketch_jan23a:25: error: within this context
radio.setMode( RF69_MODE_STANDBY );
Suggestions?
make it public instead of protected, in your local library, then when you're done, change it back (no real harm if you leave it public anyway).
Thanks, Felix.
Sorry, just to confirm it.
I haven't found in github anything about these functions, have I ?
I mean, there is nobody that has implemented this, isn't it?
Thanks a lot.