Getting Started with PICAXE and Dorji DRF4431F13 Wireless Transceiver Modules

[westaust55]

Attached is some initial work undertaken with the Dorji DRF4331F13 433 MHz wireless modules.

The hardware was supplied by forum member SAborn along with a spell check of the document
and the programming and write-up are by yours truly.

While there are many tests performed by chip and module manufacturers to determine the maximum line-of-sight range,
the testing performed here has been under my local suburban conditions with hills, cavity type double brick walled houses,
and local parklands complete with trees which are considered to represent a more "real world" test scenario.
Tests were done with a data rate of 1200 bps although the code provided is set for 4800 bps.

I did subsequent to the main write up try some settings as taken from a Dorji document which on first trial gave some
greater range - stall at 1200 bps data rate . Hopefully the time will present itself soon to undertake some further tests
with these alternative settings to see if the range improvement is consistently better. Some of the Dorji settings are
using values that do not appear within the Silicon Labs datasheet.

Note that the Silicon Labs Si4331 chip is identical to the Si4332 other than the latter has a higher power output capability.
Settings are not retained in non-volatile memory or on going into shutdown mode and must be reloaded at each power up or coming out of shutdown mode.
These Dorji modules are therefore for all intents the same as the HopRF RFM22 modules.

 

[manuka]

VERY well covered guys. MicroZed & Dorji themselves would welcome this insight- do you want them alerted? All up it looks as if Dorji's enhanced DRF7020D13 may still be preferred for many applications. Stan.

 

[westaust55]

Thanks for the offer manuka/stan.

SAborn has already covered this avenue and will be sending a copy of this tutorial as it currently stands to Dorji tonight.

 

[Goeytex]

Nice work.

A quick glance shows that the comments for Symbols nSEL and SDataIN are swapped around.

 

[srnet]

Very well written, impressed I am.

I could not see the WUT timer mentioned, runs at 32768hz from internal RC oscillator or external watch crystal. Allows you to put the module (and PICAXE) to sleep for periods from mS to 3 months or so and wake up with an interrupt. A combination of RFM42 and 20X2 had a sleep current of circa 10uA.

Just yesterday I was doing line of sight tests on the Si4332 (RFM22), 4.3kM at 25mW.

 

[srnet]

Settings are not retained in non-volatile memory or on going into sleep mode and must be reloaded at each power up or wake-up.

Is this something unique to the Doji modules ?

Register settings are retained in sleep mode with the RFM42 and the data sheet for the Si4431 says they are too.

 

[westaust55]

Apologies, wrong terminology.
Should have stated "shutdown" mode = need to reload the setting on power up or coming our of shutdown mode.

Shutdown input pin. 0–VDD V digital input. SDN should be = 0 in all modes except Shutdown mode.
When SDN =1 the chip will be completely shutdown and the contents of the registers will be lost.

Also as srnet alludes to, although not covered in the document in post 1 above, there are onboard temperature sensor,
low battery voltage detector, 8-bit ADC, three General Purpose IO, sleep/wake-up function and you can output a clock signal
to run a microcontroller or other device (for example the HopeRF HD03 series humidity sensors) that the user can make use of
as part of a more complete wireless project.

 

[srnet]

Whilst these tests were for a RFM22, its the same RF chip as the Dorji, so apart from possible antenna matching issues, results should be similar.

I have just run some tests from two hilltops, 8.2kM apart, transmitter on one hilltop receiver on another. I am trying to establish what the true receiver sensitivity of these devices is. Frequency 434Mhz, data rate 1000bps, deviation 5khz, 1/4wave wire antenna.

I had reliable reception at 12mW, about 10% success at 6mW, and the odd packet at 3.2mW and one (in 5 minutes) at 1.6mW.

Now if you can pick up one packet at 1.6mW, what sort of tweaking would be needed to make it more consistent ?

And if you could make it more consistent, that would give a LOS range of circa 20kM for a mere 10mW and simple antennas.

 

[Goeytex]

Thanks for the Tutorial, it was quite helpful.

With this tutorial, the SI4431 Datasheet, Silabs AN440, Dorji DRF4431F27 Datasheet ,Dori Demo Code & about 2 weeks of on/off programming I now have Picaxe Basic Code written for a Dorji DRF4431F27 Module that is working quite well. I am using a Picaxe 20X2 and HSPI which tightens up the code a bit compared to bit banging SPI.

This front end module operates in the USA 915 MHz ISM Band and can be programmed for up 500mw of TX Power. My Power Supply indicates ~ 300ma of current in TX mode at max power. No Range Testing yet but I imagine it will be pretty good. Next step is to include Frequency Hopping in order to stay legal at this power level.

When I am done, I will probably post the code in a new thread so as not to distract from this one.

Thanks Again

 

[westaust55]

Hi Goeytex,

Glad that you found the information useful.
I have no problems with your extending the information within this thread to keep like informaiton together.

I did start some tests with some slightly different Si4431 settings a while back which seemed to give poor close reception but slightly longer range. Needs more asessment.
Unfortunately a bout of flu and now getting ready for a move to a new house has delayed progressing this work further in the short term.
Due to their inaction when first advised of the forthcoming move, our ISP cannot do a quick transfer of phone and broadband on time since new cable is required in the street. A sign of the times and lack of pre-planning as many larger residential blocks and sub-divided into 2 or 3 blocks here with each new house wanting lines.

 

[Goeytex]

Attached is Piacaxe Basic Code intented to aid in development of further code so that a
Picaxe 20x2 can control a DOrji Si443x based RF "Front End" module.

A 20X2 was selected for its support of hardware SPI and hardware serial.


The code is made up of "functions" (subs) that perform a particluar task. With these, a person
should be able to develop and debug almost any code allowing the Picaxe 20x2 to act as a stand alone controller or as "Firmware" between the RFIC and another micro ( Picaxe, Arduino, ARM, etc).

There are 5 connections bwtween the RF MOdule & Picaxe. These are:

nSEL => C.3
nIRQ => C.5 w/ 10K pullup.
SCK => B.7
SDI => C.1
SDO = > B.2

Other Module Connections:

Gnd = Gnd
Vdd = 3.3v
SDN =>GND
GPIO 2 => 680R to LED TX State
GPIO 1 => 680R to LED RX ANT SWitch
GPIO 0 => 680R to LED TX ANT Switch

Decoupling capacitors are used where appropriate.
A 20ufcap is paralleled with a 100nf cap on the DRF Supply Pin
THERE IS NO NEED FOR MONSTER CAPACITORS !

There are two ways to configure the module.

1. WIth the Config_DRF_1 Sub routine. This does not use EEPROM Data and allows for
making faster changes when developing code.

2. With the Config_DRF_0 subroutine. This loads configuration data stored in EEPROM Memory.

I would suggest using the first when developing & testing and then when final values are figured out, use the EEPROM and remark out or delete the other routine. This will save about 700 bytes of program memory.

The SDN pin is tied directly to ground to save an I/O on the Picaxe. The module can then be reset to defaults writing $80 to register $07.

Many of the subroutines are for debugging and testing and need not be included in final code. Final code can be reduced to about 600 - 800 bytes depending upon complexity.

Enable collapsing blocks in the Editor. (Options > Editor). This allows you to collapse (hide) blocks of code so as not to clutter up the IDE with stuff you don't need to see.

If you find a bug please let me know. If you don't like my programming style / format feel free to change it to suit yourself.

Note: My Modules are for the 868 band ( Europe). However per suggestion from Dorji Engineers the 868 module can be operated in the 915 range with only about a 2dBm loss. While not ideal, it is the only option for 915 MHz (USA ISM BAND) using a Dorji module as they do not stock any 915MHz modules. 868 and 433 MHz are NOT in any legal North American ISM band. 433MHz can only be legally used at extremely low power in the USA. However, 915 MHz can be used at up to 1 watt with frequency hopping.

Frequency hopping in the 915 band will be my next programming endeavor. However, I may order and use HOPE RFM23BP modules for this as I have had some trouble with the DORJI DRF4431F27 module. It seems the way this Dorii transceiver module is designed, it always draws 280ma when transmitting no matter what the power level setting. This is a poor design. With a better design, the TX power consumption should be closely related to the power level setting. I am guessing that the HOPE Module will do better and the code will be almost identical.

I also have some 20dBm 2.4GHz modules get working. (USA LEGAL). These were sent to me from INHAOS for evaluation. They have a data rate of
either 1Mbps or 2Mbps and should be good for a range of about 300m with a decent antenna. A small 5 element YAGI (legal at 2.4GHz) should extend the range considerably.

 

[techElder]

Goeytex, the use of "CALL" instead of "GOSUB" is a little out of the ordinary, but your routines make me want to finally jump into RF for the PICAXE.

Is it necessary to have ALL of those configuration values in the program? Doesn't a reset of the module supply most of them?

What do the EEPROM data values represent at the end of your routines?

 

[srnet]

Is it necessary to have ALL of those configuration values in the program? Doesn't a reset of the module supply most of them?

What do the EEPROM data values represent at the end of your routines?

You can probably remove some of them, but setting up the RF chip for packet transmission does require the configuration from default of some 40 registers.

The RF device is extremly versatile and can be set for a wide range of frequencies, deviation, transmission mode, bit rates, I\O options, timers, AD, temperature sense, low battery detect, and all sorts of options for packet transmission.

So there is not really a default configuration.

 

[Goeytex]

What do the EEPROM data values represent at the end of your routines?

The Si RF4431/32 RFIC has 128 Registers. Some of these are read only while others can be written. Registers are read or written by using SPI.

The way I did it was to have each EEPROM location represent the sameregister location, so that EEPROM location 0 represents SI4432 Register 0 , and so on. So for example The hex value in EEPROM location $22 will be written to Si 4432 register location $22 when the config routine called at startup.

The register map and what each bit in each register does can be seen in SILABS AN440.PDF as well as in the Excel Configuration Spreadsheet provided by SILAMS.

 

[Hooter]

WestAus55 - I am having trouble reading the RSSI register ($26) on the receiver with your program provided:

DO
Buffr_Strt = 136 ; EEPROM location for first character/value to send
Buffr_Leng = 20 ; first byte is 0 so 1 less than actual characters to send
GOSUB Data_Rx ; go receive the packet of data and display contents of Rx FIFO buffer
RegAddr = RSSI
GOSUB DRF4431F13Read
SERTXD ("RSSI = ", #Received,cr,lf,cr,lf)
;
LOOP ; loop forever
Everything else works perfectly. I have replaced $26 with other registers just for testing purposes and that reports what is in the register correctly
but I only ever get a '0' reported fro register $26.
Any suggestions welcome
Cheers
Hooter

 

[srnet]

Dont know the answer, but reading the RSSI meter should give you a background noise level of around 44.

You appear to be reading the RSSI register after the packet has been received, and thus after transmission has ceased ?

 

[Hooter]

srnet - Thanks for the response. I will have to do a bit MORE reading of the data sheet to see how long the RSSI level is kept in the register.
Cheers
Hooter

 

[srnet]

I think you will find the answer is not very long, if you find the answer that is.

The RSSI updates all the time as a background process, so you really need to read it once packet reception has started but before it has finished.

 

[Hooter]

The data sheet suggests the RSSI level is measured during the preamble. Would the register not hold the data until the next read whence it would them be updated?
The code snippet above from WestAus55's program suggests it should fit in with this requirement. I have tried heaps of variations to no effect - but will keep plodding along.
Cheers
Hooter

 

[srnet]

The data sheet suggests the RSSI level is measured during the preamble

Where does it say that ?

 

[Hooter]

8.10. RSSI and Clear Channel Assessment

For CCA, threshold is programmed into rssith[7:0] in "Register 27h. RSSI Threshold for Clear Channel Indicator."
After the RSSI is evaluated in the preamble, a decision is made if the signal strength on this channel is above or
below the threshold.

 

[srnet]

8.10. RSSI and Clear Channel Assessment

For CCA, threshold is programmed into rssith[7:0] in "Register 27h. RSSI Threshold for Clear Channel Indicator."
After the RSSI is evaluated in the preamble, a decision is made if the signal strength on this channel is above or
below the threshold.

I would that to mean it polls the RSSI from the time the preamble is detected until the time is finishes, when CCA mode is selected. If the RSSI exceeds the threshold for any of these polls, it sets a flag\interrupt.

No mention of it saving the highest or average RSSI ........

 

[Hooter]

Thats how I read it as well. I would think that during the preamble is the only time the RSSI level would be read and at that time logged in to the RSSI register $26 -
then the same value used for the CCA purpose if it was enabled. Or am I being too presumptuous?

 

[srnet]

I would think that during the preamble is the only time the RSSI level would be read and at that time logged in to the RSSI register $26 -
then the same value used for the CCA purpose if it was enabled. Or am I being too presumptuous?

Does not work like that, and the data sheet does say that the RSSI register can be read at any time.

You can use the RSSI function for a field strength meter, one of my applications does just that, turns the receiver on and polls the RSSI a few times, and shows the result on a screen. Very useful for tuning antennas and the like. No need to be transmitting a packet, it just senses RF.

 

[Hooter]

Ok - with that in mind, why is Westasu55's program not returning the RSSI level in register $26 - maybe it is - I just can't read it. My application is a transponder not being seen until a particular RSSi
level is received ie a particular distance from an auto door. Are you using the same method as WestAus55 in your field strength meter?

 

[srnet]

This is the section of code for the RSSI function of my Satellite Groundstation receiver, its for the 28X2, so it uses HSPIOUT rather than bit banging. I am using the RFM22 module, but that uses the same Si4432 RF IC as in the Dorji modules. I use it to check the field strength from the transmitters, works quite well, I use it often.

It only updates the display if the RSSI is above 42, thats close to background noise. The limit of Si4432 packet reception in an RSSI of around 44 -50

RSSImeter:
		
		setfreq m16						'run at 16Mhz so RSSI is sampled faster
		gosub RXon
		low PXLED
		wvar1 = 0
		
		for loopv1 = 1 to 25
			low NSEL 				
			HSPIOUT($26) 				'RSSI register
			HSPIIN(RSSI) 				'collect RSSI value
			high NSEL 	
			wvar1 = wvar1 + RSSI
		next loopv1
		
		RSSI = wvar1 / 25
	
   	        if RSSI > 42 then 					'background noise is about RSSI 38
			high PXLED
		else 
			low PXLED
		end if 
		
		setfreq m8						'back to 8Mhz for LCD writes
		gosub home1LCD
		serout TXLCD, baudLCD, ("RSSI ",#RSSI,"  ")
		serout TX, baud, ("RSSI ",#RSSI,CR,LF)
			
		if PCBswitch = 0 then 				'press the switch to run from main: again
			gosub RXoff
			goto main
		end if	
		
		pause 500
		goto RSSImeter

Ok - with that in mind, why is Westasu55's program not returning the RSSI level in register $26 - maybe it is - I just can't read it.

No idea ....... Is the receiver turned on ?

 

[Goeytex]

Hi Guys,

Clearing the FIFOS.

I noticed that in the posted demo code the ClearFIF0 subroutine attempts to clear the FIFOS by reading bits 0 and 1 in Register 0x08. I don't think will work since according to AN440 these are cleared by writing to this register.

The interrupts are cleared by reading registers 0x03 and 0x04, but I'm pretty sure that Register 0x08 need to be written instead.

From AN440 p14:

RX FIFO Reset/Clear.
This has to be a two writes operation: Setting ffclrrx =1 followed by ffclrrx = 0 will clear the contents of the RX FIFO.

TX FIFO Reset/Clear.
This has to be a two writes operation: Setting ffclrtx =1 followed by ffclrtx = 0 will clear the contents of the TX FIFO.

Goey

 

[Goeytex]

Hooter Posted:

...WestAus55 - I am having trouble reading the RSSI register ($26) on the receiver with your program provided:

I have the same problem with the Westaust Code. RSSI is always reported as "0". However, a valid packet is received, so the receiver was turned on, but may be off by the time RSSI is being read.

I will be looking in to this and hope to have an answer an answer soon.

 

[Goeytex]

RSSI Stuff:

The problem with the code is that RSSI is attempting to be read after the packet has been received and the DRF443x has reverted to standby mode where RX is off. Therefore a value of 0 is returned. To read the RSSI "on the fly" it must be read after the CCA threshold is reached and before the packet is done and the transmitter is still on. There are several ways to do this. One is to read the RSSI upon the detection of a valid preamble. Another is to read the RSSI after the detection of a valid sync word but before the packet is completely received and the DRF reverts to standby / idle. I like the sync word method. I got poor results with the preamble method but this might could be corrected with a longer preamble and or/ possibly a higher RSSI threshold.

A GPIO can be programmed to go high whenever a valid sync word is detected. See Registers $0B, $0C or $0D. Connect this GPIO to a Picaxe input pin. When this signal goes high, immediately read the RSSI. Then wait for for the valid packet interrupt on the nIRQ Pin.

 

[srnet]

but I'm pretty sure that Register 0x08 need to be written instead.

Thats correct, you need two seperate writes to register $08, $02 then $00.

 

[srnet]

The problem with the code is that RSSI is attempting to be read after the packet has been received and the DRF443x has reverted to standby mode where RX is off

Very likely, see post #16 and #18

What works will depend on the data rate and length of packet, the Si4432 will flag a valid Sync word, but you need to be sure that the PICAXE will respond to that and read the RSSI before the packet has finished.

 

[Goeytex]

Actually, more than likely. This was confirmed by testing a real setup and looking at signals.

My suggested method was also tested to work with the WestAust Code which uses a data rate of 4800 BPS. However, at higher data rates and/or shorter packet lengths it may be prudent to use an interrupt and/or to read the RSSI data immediately after the preamble is validated or shortly after the CCA bit is set.

In the case of Westy's code, the GPIO pin stays high for 51ms. That is the time from the sync word being validated to the packet being validated. The transmission (carrier signal) will end several ms before the 51ms. So I estimate that we have about 45ms from the time the GPIO pin goes high to read the RSSI. More than enough for a Picaxe without having to use an interrupt.

But .... In the WestAust code, the SPI is beiing bit banged, which is agonizingly slow with a Picaxe. I modified the Code for Hardware SPI and was using a 20X2 at 16mhz. I don't use anything other than an X2 Picaxe with these modules because of the enhanced performance of HSPI over bit banged SPI.

 

[srnet]

I don't use anything other than an X2 Picaxe with these modules because of the enhanced performance of HSPI over bit banged SPI.

Indeed, bit banging on an 18M2 seems perverse, when a 20X2 can do SPI directly and is a whole lot faster.

The code I have put in the projects area is for the RFM22, but the same code would drive the Dorji modules also.

I have spent hundreads of hours testing and using that TX and RX code on 'real setups' it is reliable.

 

[westaust55]

But .... In the WestAust code, the SPI is beiing bit banged, which is agonizingly slow with a Picaxe. I modified the Code for Hardware SPI and was using a 20X2 at 16mhz. I don't use anything other than an X2 Picaxe with these modules because of the enhanced performance of HSPI over bit banged SPI.

Yes, an 18M2 was used for the testing and tutorial which limited the program to bit banging for data transfer. This was to assist SAborn at that time who was seeking to compare several wireless modules and had supplied the hardware.
Often in my own case, I am also using i2c devices conencted to the PICAXE and thus do not use the hardware SPI very often but the inbuilt SHIFTOUT command in the X1 and X2 parts is (from speed tests long ago using an X1 part) about 4 times faster than bit-banging and thus still provides a reasonable improvement and another reason to consider the X2 parts these days.

Notwithstanding that the use of an X2 part maybe the best position, it is also useful to have more universal code that will function across at least most of the range of PICAXE chips since not everyone wishes to use the latest or most "powerful" PICAXE chips for their projects.

Having got a few other projects and concerns out of the way, I may shortly return to undertake some extra testing myself using these DORJ modules.

 

[Goeytex]

Another way to get the RSSI on the fly is to program a GPIO to indicate the state of the Clear Channel Assessment bit. This is done via Registers $0B or $0C or $0D. Then connect the GPIO Pin to a Picaxe input. IF the input goes high , the the RSSI level is above the RSSI threshold set in Register $27. The RSSI can then be read via Register $28 as long as the RX is turn on. The output of the GPIO pin will stay high as long as the RSSI value remains above the programmed threshold.

In my testing at 915mhz, a data rate of 4800, and a preamble length of 40 bits, the signal remains high for about 180 ms. This is the time that the TX was actually on.

The threshold level set in register $27 should be above the noise level at the set frequency. In my case, running a test at 915.5Mhz, I had to increase the RSSI threshold from the default value to a value of 50 decimal. This could be set higher and code written so that only packets above that threshold level are accepted.