Identifying if HCW/HW or CW/W in software - Hot or not?

[joelucid]

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:

Code: [Select]

#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

[Felix]

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?

[joelucid]

How 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

Code: [Select]

#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 );
}

[TomWS]

Good job, Joe!

One step closer to the Nifty-Thing!

Tom

[Felix]

Great stuff, thanks joe!
BTW one caveat I see is this assumes a well matched antenna.

[joelucid]

BTW 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

[Felix]

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?

[TomWS]

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

[joelucid]

If 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

[joelucid]

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.

[TomWS]

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

[joelucid]

Yes, 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!

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).

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

[Felix]

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.

[TomWS]

The only better thing than this is having a logic pin on the RFM69 itself.

WHAT A GREAT IDEA!  Whatcha think, Joe?
 

[perky]

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.