SERIN & simple RF modules clarificaton needed

[premelec]

I have seen reference many times to noise on simple receiver modules hanging up SERIN which evidently just stays active looking at the noise - Is this correct? [command description doesn't seem to address this].

erco recently referenced http://www.romanblack.com/RF/cheapRFmodules.htm which gives a detailed analysis of some cheap modules - from this write up it appears there is an AGC function [Auto Gain Control] which quiets the noise if there is a strong local signal and holds the gain down for a while after the signal is gone - It would seem that PULSIN could be used to look for a long carrier input setting back the AGC and then switch to SERIN or simply record subsequent PULSIN values which could be used to control something by their length... Does this seem a viable strategy? [and I'm not clear on just what terminates a SERIN]

I've got some of these $1 modules and will try some things - the only thing I've discovered so far is how unstable the TX frequency is by listening with a good communications receiver - not a really narrow bandwidth so presumably the RX is also pretty broad.

Your comments welcome - thanks...

 

[hippy]

It could be possible to monitor the RX data and, if no activity, assume there is a local carrier but no data being transmitted, enter SERIN in the expectation that data will arrive. Not sure how reliable it would be though. There would be some possibility of getting a false trigger, entering SERIN when no data was due, and getting stuck in that SERIN.

 

[inglewoodpete]

It's probably worth doing some experimenting with the RFIn and RFOut commands, available on all current PICAXE models except the 08M2. The only catch is that the NKM2401 protocol only allows you to send/receive 8 bytes at a time, but at least the data is accurate.

I recently bought a pair of Rev-Ed's AXE213 stand-alone encoder pairs for a duplex link (2 x Tx, 2 x Rx (RFA001)) I needed for a project. Unfortunately, one of the RFA001 receiver boards seems to be badly out-of-spec, so I had to shelve the idea and use a long cable instead(deadlines, deadlines ~sigh~). I'll do some further experimenting when I get a chance - I'm caught up in a series of commercial project proposals at the moment.

 

[hippy]

and I'm not clear on just what terminates a SERIN

SERIN will continue to execute until all data requested is received or the command timesout if a timeout is used.

So, for normal reception, any specified qualifiers will have been received, followed by bytes / characters for any (non-#) variables and numeric strings for any # variables. Numeric strings must be terminated by a non digit character.

If the input signal remains at the idle level specified by the baud rate (N=low, T=high) for the length of the timeout while waiting for a byte to be received the timeout is activated if provided for.

For dumb RF modules the timeout is often continually restarted because of noise on the line, and the SERIN never completes because that noise won't match the qualifier(s) which are effectively mandatory to prevent corrupted data being received.

 

[premelec]

hippy - your #2 answer was what I was suggesting - finding the 'long quiet' through PULSIN having to be a certain length which would also actuate AGC - however also I was thinking I could get a bunch of control codes [not ASCII stuff] by simply measuring subsequent PULSINs whose lengths would correspond to various actions. I'm using M2 parts so timeout not happening.. if the RX AGC function actually exists and persists that's key and is also likely why these modules ever work Hence the warm up TX transmission simply kicks the RX gain down. Black's discussion [see #1] indicates quite a bit about this and he also didn't have much good to say about Manchester coding... Anyhow I'll give it a go - thanks for the replies

 

[hippy]

It does sound possible, and you could perhaps even use SERIN without qualifiers to grab a time period of data in each variable or, determine which are valid pulse sequences and which are noise.

In most cases people are wanting to use SEROUT for easy ASCII and binary transmission and want an equally easy SERIN to retrieve what's sent. If going 'off piste' and using a different protocol the standard rules probably don't apply.

I had always wondered about X2 backround receive of dumb RF data, how feasible that is. I thought noise and lack of synchronisation might make that impossible but perhaps not if there is 'silence' before the genuine data.

Unfortunately, at home, it's such a noisy 433MHz environment that dumb RF just isn't viable so I have given up on that.

 

[MikeM100]

It might be useful to get a better understanding of the 'data slicer' circuitry used within data RF receivers ? Messrs Maxim explain it rather well here:

https://www.maximintegrated.com/en/app-notes/index.mvp/id/3671

 

[PhilHornby]

Noise

It would seem that PULSIN could be used to look for a long carrier input setting back the AGC and then switch to SERIN or simply record subsequent PULSIN values which could be used to control something by their length...

What I found, when trying to decode the output of a commercial HC1527-based remote, was that you can't easily use Pulsin to detect these 'quiet' periods. In my case, I was looking for the signal going low for about 6.5mS. In practice, there is so much noise, that the Pulsin keeps completing; and by the time you've checked its value and re-issued it you might well have missed the beginning of the actual pulse you are looking for.

I ended up doing this, instead:-

(@32MHz)

symbol PREAMBLE_DETECT_LOOP_COUNT = 14                ;This is used to detect the low-going preamble pulse. Adjust with care!


      bptr = BitStore                                 ;point at our storage location
      b0 = 0                                          ;counter
      Do 
            pulsout Debug_Pin,1
            if Data_Pin_Alt = 0 then                  ;if RF is low
                  inc b0                              ;inc count of RF seen low
            else
                  b0 = 0                              ;RF high = reset the count
            endif


loop while b0 < PREAMBLE_DETECT_LOOP_COUNT      ;wait until we detect the preamble (6.6mS low pulse)

or you could take the hardware approach (ala Saunj's method here).

Once the start of the data is detected, you have to do as you suggested and store it for later analysis; there's not enough processor oomph to do anything on-the-fly.

It's probably worth doing some experimenting with the RFIn and RFOut commands, available on all current PICAXE models except the 08M2. The only catch is that the NKM2401 protocol only allows you to send/receive 8 bytes at a time, but at least the data is accurate.

I did some tests with RFIn/RFOut a while back, and was surprised to find that the data wasn't always accurate! In other words, while they undoubtedly help, they don't represent a complete error-checking solution by themselves.

Unfortunately, at home, it's such a noisy 433MHz environment that dumb RF just isn't viable so I have given up on that.

I reckon you should fight fire with fire! Just leave something transmitting continuously until your neighbours conclude that they've got a problem with their equipment and switch it off

 

[premelec]

Thanks for additional info - the MAX1473 looks good and costs a lot... I am going to try long silences detection like 200ms. I notice the irony that preambles have been mentioned to 'wake up' the path whereas likely they are more to make sleep closer [i.e. reduce RX gain]. My apps are pretty slow so I can afford repeats and check.

 

[PhilHornby]

I don't think you can generate 200mS of silence...

I am going to try long silences detection like 200ms.

Since my breadboard currently has a cheapo (FS1000A) 433MHz transmitter on it, I thought I'd try a test. (FS1000A Vcc to B.4 and DATA (cunningly marked "ATAD"!) to B.5 - Picaxe 14M2)

#picaxe 14M2
#Terminal 4800
#Slot 0
#No_data
#No_end
;
; 2 pins control the FS1000A 433MHz RF module
;
Symbol EnableRF            = B.4          ;Power for RF module, only when req'd
Symbol RFDataPin           = B.5          ;connects to RF Xmiter DATA input.


;
;     Set o/p ports.
;
      dirsb = %00110000                   ;B.4 & B.5 are o/p
      HIGH EnableRF                       ;Radio ON
do
      for b0 = 1 to 5
            toggle RFDataPin              ;Generate a signal
            pause 150                     ;sort of works up to 100mS
      next b0


loop

At 75mS (+ overhead for the do loop), it's looking OK:


but at 150mS it's not so good :

The signals were captured using the matching? receiver, the 'er "XY-MK-5V" (so it says!)

 

[premelec]

Thanks PhilH - I guess I'll find out - I would think CW signal of ok magnitude would pretty well quiet the RX but maybe it has another AGC function when on too long... I haven't figured out your code yet... - maybe TX doesn't stay on... I'll listen with a communications receiver... My RX boards say "RF-5V" - just a couple of transistors and LM358 op amp... "XD-FSD" 433.92 MHz TX boards... Also FS1000A showing... like yours...

 

[PhilHornby]

I haven't figured out your code yet... - maybe TX doesn't stay on...

Actually, I'm not surprised - I just cut-and-paste it from somewhere else - that "for...next loop" is totally superfluous! I did try connecting the FS1000A directly to +5V, but it makes no difference. (It was already wired to be turned on and off by the Picaxe, so that's how I left it.)