Roman Black RF protocol in GCBasic ?

[Jacques Nilo]

Hi all
I am wondering if any one has ever tried to program Roman Black RF protocol in GCBasic.
If so could you share your code ?
Many thanks
Jacques

[Keith]

I have used his applications in particular his digital sound code. I think I have the original source code somewhere in my archives. I wouldn't know where to start with a GCB translation though.

[Jacques Nilo]

OK. Here it is.
Transmitter GCB code

; Testing of Roman Black RF protocol on cheap 433Mhz TX/RX modules
; Adapted for GCBasic from:
; http://www.romanblack.com/RF/cheapRFmodules.htm
;
; Transmitter code example
;
; J. Nilo, April 2016

;Chip Settings
#chip 16F1508, 8

#define RfOutPort PORTA.5
Dir RfOutPort out

sub rf_send(txdat)
wait 170 us
RfOutPort = 1
wait 79 us
RfOutPort = 0

Repeat 8
  wait 19 us
  if txdat.7 then wait 50 us
  RfOutPort = 1
  wait 79 us
  RfOutPort = 0
  rotate txdat left simple
end Repeat
end sub
;
; Your Main code here
;

Receiver code (trickier... )

; Testing of Roman Black RF protocol on cheap 433Mhz TX/RX modules
; Adapted for GCBasic from:
; http://www.romanblack.com/RF/cheapRFmodules.htm
;
; Receiver code example
;
; J. Nilo, April 2016

;Chip Settings
#chip 16F1709, 8

; Setup LCD Parameters
#define LCD_IO 4
#define LCD_NO_RW
#define LCD_Speed fast

; Define Hardware settings
#define LCD_RS PORTC.5
#define LCD_Enable PORTC.4
#define LCD_DB4 PORTC.0
#define LCD_DB5 PORTC.1
#define LCD_DB6 PORTC.2
#define LCD_DB7 PORTC.3

; To be included in Main
; Define port receiving RF signal
#define RfInPort  PORTC.7
Dir RfinPort In

; TMR0 at 500kHz --> set prescaler at 4: (8Mhz / 4) * (1/4)
; (need to be adjusted if you change the 8MHz chip frequency)
InitTimer0 Osc, PS0_4

; Initialization of received data (dim must be > nrpp, defined below)
dim rxdat(10)
;
sub rf_receive(nrpp)
; This function receives an RF packet of bytes in Roman Black Pulse
; Period encoded format. The packet must have nrrp valid contiguous bytes
; or the function will not exit. There is no timeout feature, but could be added
; TMR0 is running at 500kHz, so 200uS = 100 TMR0 ticks
;
; Adapted for GCBasic from Roman Black C source
;
rrp_bytes = 0

; Loop until nrrp contiguous RF bytes have been received
do while (rrp_bytes < nrpp)
  do
    TMR0=0
    wait until !RfInPort                'wait for input / edge
    wait until  RfInPort                'wait for input \ edge
    rrp_period = TMR0                   'grab the pulse period
    if (rrp_period >= 100) then exit do 'valid start pulse detected
    rrp_bytes = 0                       'clear bytecount if still recv noise
  loop
;
; Now we had a start pulse, record 8 bits
  erreur = 0
  repeat 8
    TMR0=0
    wait until !RfInPort                'wait for input / edge
    wait until  RfInPort                'wait for input \ edge
    rrp_period = TMR0                   'grab the pulse period
    if (rrp_period >= 100) then         'if >=200uS, is unexpected start pulse
      erreur = 1
            exit repeat
    end if
    if (rrp_period < 61) then           '61 = 122uS
      rrp_data.0 = 0
    else
      rrp_data.0 = 1
    end if
    rotate rrp_data left          'save the good bit in rrp_data
  end Repeat
;
; gets to here after nrpp good bits OR after an error (unexpected start pulse)
  if erreur = 1 then
    rrp_bytes = 0
  else
      rotate rrp_data right
        rxdat(rrp_bytes) = rrp_data
    rrp_bytes = rrp_bytes + 1
  end if
loop
end sub
;
; Your Main code here
;

A bit crude. Not extensively tested but seems to work.
Jacques

[William Roth]

The receiver code is very similar to that used by the DHt11 Humidity Sensor

[Jacques Nilo]

Yes. The main difference seems to be that the DHt11 driver is using an internal counter rather than TMR0 to compute the signal period. Perhaps a better idea ?

[William Roth]

I'm sure that either way is ok and the method is a matter of preference. I may actually try a few things with some of these "dumb" RF modules as I have a box full that need a purpose.

The receivers on my cheap ASK modues are better than most with a real RFIC chip instead of an LM358 OPAMP, so a bit of testing should show if there is very much to gain with this protcol vs spending a few dollars more for an SPI based "smart" module that can easily do 300 meters with a data rate of 40K BPS

I have been experimenting / testing with a PIC16F1614/16F1619 using the Signal Measurement Timer (SMT) and this may be an ideal application for testing, I think it may be possible to have the SMT to do the most of work in the background while the core MCU is off doing other stuff.

Not sure where we are with good chipdata files on this excellent newer family of chips but if you are interested let me and I can probably get something to you,

Bill

[William Roth]

Update:

My receivers are DORJI DRA886RX and cannot operate at the speeds used by Black Knights protocol. My receivers look like the ones in the second photo in the link.

To get reliable comms, the TX off time had to be increased to 120 us and the Data "0" was increased to 50us and a data "1" to 100us.

I see little to no benefit with the BN protocol as these Dorji Modules work OK at both 2400 and 4800 baud.

William