HC-12 433 mHz module + Ard + Kerui PIR

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 8.

Moderator: Benj

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi Martin

B5 or D2?
---------
D2 is connected to INT0 by default, you are correct.
I didn't use B5 at all, as I used ssd1306.
I have to update the 'I have to change pin B5 to pin d2'.
I didn't use B5 as an input, just used B5 (calculation icon) to change it to D2 to pull the input high.
Saved some time to create a new icon.
That is it.
Attachments
HC12_Rx_3.fcfx
(31.4 KiB) Downloaded 115 times

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by mnf »

Hi Viktor,

I tried this - and no joy. Modded slightly and working again on my test rig. I think the issue is that there are several 'writes' to D2 - this will fire an interrupt and change the pin to an output (it needs to be an input) - seems to mess things up.
Note the AVR chips don't have many pin-change interrupts available, and they are on fixed pins

I've gone back to UART output as I don't have the same display to test with.

No time to try the noise handling before work :-(
HC12_Rx_4.fcfx
(31.59 KiB) Downloaded 128 times
Martin

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi Martin

I have to slow down a bit.
Will come back to this issue after I make a new PCB and signal will be better.
Appreciate your help.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by mnf »

A version that allows simulation.
HC12 SIm.fcfx
(26.47 KiB) Downloaded 112 times
I've modified to save the data received to a single long variable instead of an array and rearranged pin change slightly - it needs to be as fast as possible - imagine a transient 'pulse' in the middle of the long low - the 'up' change will register - but if the MCU is still in the PinChange interrupt handler then the 'down' will be missed.

It doesn't do anything on short 'pulses' - I think it might need to go back to previous state / not clear the timer? (In the above scenario - the timer will be reset so the long low will have 'half' the correct length)

Martin

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hello Martin
I have tried your new version. No go...
------------------------
What do we have in a state machine logics?

On any edge of pinD2 change:
1. raising edge: state=Start. Is it a noise? (.pullse < 50) && (state != IDLE)
No ->
Is it -> a 350mS pullse? (.pulse >= 300) && (.pullse < 400)
No
2. falling edge: state = Idle. start Timer1, back to state = Start
3. raising edge: state=Start. Is it -> a 350mS pulse? (.pulse >= 300) && (.pulse < 400)
No -> to state = Idle
Yes->to state= SOF (start of frame)
4. falling edge: state=SOF.
Is -> (.pulse >= 30 * 350) && (.pulse < 32 * 350) // end of Preamble?
Yes -> state_Data
No->Stop TImer1, state=Error
Note: system is stopped at state=Error

N 4. falling edge: is the problem.
Duration of LOW (31*350uS) should be apprx 11mS or 350*31=10850uS

If we found pulse N1 = 350uS, the end of Preamble LOW will be at the
start of raising edge (D2change N3), not at the pulse N4 falling edge.
Is it correct?

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by mnf »

Hi Viktor,

Seems to simulate OK - note that as mentioned the 'noise' handling doesn't do anything yet.
Add a breakpoint at start of PinChange to simulate. This should work on hardware if you remove the SendTest(value) before the loop.

The 'action' is with 'ideal' timings shown and ignoring errors.

CurrentState, PinState (Pin 2 - (0) = low (1) = high.), pulse_length, NewState

Idle (0) - Waiting for a message Timer is stopped.

1) First Pin change
IDLE (1) 0us (timer starts now) START - Timer started - now looking for a high pulse (350us)

2) START (0) 350us SOF - Received initial pulse - now looking for a long low.

3) SOF (1) 31 * 350us DATA - Long low received - now looking for data.

This block repeats

DATA (0) 350us READ0 - Short high pulse rcvd - check a long low (3 * 350us) for 0 bit
DATA (0) 1050us READ1 - Long pulse (3 * 350us) rcvd - check for 350us low for 1 bit.

READ0 (1) 1050 DATA - Add a 0 (bit) to data received
READ1 (1) 350 DATA - Add a 1 bit to data

After each data bit received - check if we have 24 bits
Change state to END if so. - disable timer

Martin

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi Martin

Code looks good.
I don't thing it is a code.
In real life the output of 433mHz receiver is very noisy.
I read on www that some wait for the second or third packet to start processing data.
I would be able to fix the shcmitt trigger (maybe) next week of week after.
And will try your code again.
Today the test wasn't OK.

Thanks Martin.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by mnf »

Hi Viktor,

I'll think some on the noise handling over the weekend - one idea is to 'ignore' some pulses before attempting to read a message - for example 24 bits should have ~50 pin changes so ignore 250 pin changes to skip the first five messages (or so) then wait for a 'low' period. Do you know what the gap between messages is? If it is comparatively large, then it makes detecting it easier?

Martin

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

what about low-pass software filter?

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hello Martin

I have check the rxb12 433mHz receiver (again).
Looks like the SYN470R chip Automatic Gain Controller output level should be pulled down or up before receiving the ttl data.
I tried both ways. If D2 by setup = 0, no input at all.
If D2 by setup = HIGH, it works (with RCSwitch library).
Some people solder the low pass RC filter, etc, but as I understood only Schmidt trigger clean up noise effectively.
-------------------------------------
From the manual:
During quiet periods (no signal) the data output (DO pin) transitions randomly with noise. Most
decoders can discriminate between this random noise and actual data but for some system it does
present a problem.
There are three possible approaches to reducing this output noise:
1) Analog squelch to raise the demodulator threshold
2) Digital squelch to disable the output when data is not present
3) Output filter to filter the (high frequency) noise glitches on the data output pin.

The simplest solution is add analog squelch by introducing a small offset, or squelch voltage, on
the CTH pin so that noise does not trigger the internal comparator.

Usually 20mV to 30mV is sufficient, and may be achieved by connecting a several-megohm resistor from the CTH pin to
either VSS or VDD, depending on the desired offset polarity. Since the SYN470R has receiver AGC
noise at the internal comparator input is always the same, set by the AGC. The squelch offset
requirement does not change as the local noise strength changes from installation to installation.
Introducing squelch will reduce sensitivity and also reduce range. Only introduce an amount of
offset sufficient to quiet the output. Typical squelch resistor values range from 6.8MΩ to 10MΩ.
--------------------------------
My rxb12 receiver has Dout connected to CTH pin (both pins are connected), so I have no way to use this CTH pin to deal with noise.
I tried to use a button (in software) connected to D2.
By using button function ReadState I could stop constant reading of d2 noisy input, but only one program handles the signal with noise, it is Arduino library RCSwitch. As this library is based on other Arduino libraries and as RCSwitch uses some not available if FC8 functions, I didn't spend too much time with it.
---------------
Will try to solder a Schmidt trigger (somehow) to PCB next week.
Attachments
block_diagram_1.jpg
block_diagram_1.jpg (72.3 KiB) Viewed 77595 times

chipfryer27
Valued Contributor
Valued Contributor
Posts: 618
Joined: Fri Jun 06, 2014 3:53 pm
Has thanked: 184 times
Been thanked: 195 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by chipfryer27 »

Hi

As mentioned earlier, an alternative may be to sample.

The shots below illustrate the concept and instead of actually sampling I have just toggled a pin high/low to illustrate where sampling could take place. Of course chip speed would be a major factor in actually doing this (I was using a PIC @8MHz) but I'm sure you get the idea.

I used the generator of last week and this is shown as CH0. It is connected to an IOC pin.

When triggered the ISR disables IOC and enables a Timer Interrupt of 350uS. This ISR toggles Ch1 (but could be sampling). Clearly very simplistic, but does illustrate nicely.

Capture-1.jpg
Capture-1.jpg (48.37 KiB) Viewed 77572 times
Datastream

Capture-2.jpg
Capture-2.jpg (43.07 KiB) Viewed 77572 times
Preamble close up

Capture-3.jpg
Capture-3.jpg (34.36 KiB) Viewed 77572 times
"One" close up

Capture-4.jpg
Capture-4.jpg (35.56 KiB) Viewed 77572 times
"Zero" close up

If you were suffering from random noise, say going high unexpectedly, then it would need to occur at the exact time of sample to be of any effect. We sample / toggle once in every 350uS which is a time period for transmission, and therefore 4 x samples captures either a 1 or 0. Processing later would identify which (including preamble / valid data etc).

Sorry to be brief, and hope this may help.
Regards

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi
As I understood correctly:
- if state of D2 pin changed
- disable IOC (D2)
- start 350uS timer
- enable IOC
- wait for pin D2 change
- disable IOC
- measure the duration

Is it correct?

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by mnf »

A brief attempt at a version that 'ignores' noise. Again - remove the call to SendTest to try on hardware (I'd also remove the test of issim too - it's an extra branch and sped is good here)
HC12 SIm.fcfx
(27.31 KiB) Downloaded 120 times
As an aside - rather than use 'pos' and a shift to add in a 'one' bit - it might be quicker to have a mask and just shift this once on each bit - does shift >> 5 take more cycles than shift >> 1?

Basically - I've assumed that noise will only occur on low pulses (ie line may go high briefly, but is less likely to go low when pulled high)
If the initial pulse isn't 350us - back to idle (as before) to handle noise between messages.

If a spike occurs and the time is less than expected low length (so 31 * 350us start of message) or 350us or 1050us for 1 or 0 bit - then continue timing without changing state

I did add a pulse_count as well (removed here) - which would bail on too many pulses (what is too many?) It's still possible to get stuck in an unknown state, it relies on pin changes - so if the line goes low or high and stays there, it will never change state. However, because it is interrupt driven the main program will continue to run - just will never get a message - which is correct - no message will have been received - but might be good to display an error message "tamper detected"?

By replacing the timer with a timer interrupt - it is possible to add a timeout feature.

Mqrtin

chipfryer27
Valued Contributor
Valued Contributor
Posts: 618
Joined: Fri Jun 06, 2014 3:53 pm
Has thanked: 184 times
Been thanked: 195 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by chipfryer27 »

Hi

I seem to have deleted my first attempt at replying... Doh..!

If using the sampling method, and I'm not saying it's better just a possible alternative, then the concept could be

1) Enable IOC on D2 (or perhaps wait until high)
2) In the IOC handler, disable IOC on D2 and enable a Timer Interrupt set at 350uS. This interrupt will trigger every 350uS thereafter.
3) In the Timer Interrupt handler sample pin D2 and store.

The above is simplistic and very much dependent on your processor and speed. Faster is better as the time taken to process instructions could limit suitability.

You could perhaps increment a counter each sample, and store each sample in an array (referenced by counter). Perhaps start filling array Preamble then at count "x" start populating array Address etc, disabling the Timer Interrupt after the required samples (32 for Preamble, 80 for Address and 16 for Data).

Once captured it would be straight forward to convert the captured stream into 1/0 for further processing.

Depending on processing speed you may want to add/adjust a delay from when triggered to enabling the Timer Interrupt so that each sample occurs in the middle of each time period.

Regards

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi chipfryer

I have to study about your 'sampling design more.
Will answer shortly.

Thanks

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hello Martin

Pulse count is a good idea.
I was thinking about it.
Say... If we have 4 pulses in one bit, each pulse has 3 raising/falling edges... than one bit shouldn't have more than 3*2=12. Is it correct?

Testing you program
No go...
For some reason I belive that Timer1 component doesnt' work.
I think Ben warned about some float as return and possible complication in converting it to int or Uint , etc.
I looked at provided by you link on J1850 (car diagnostics program).
I started to test the C-code TimerOn/Off with different results.
Cannot understand what do I do wrong, but I cannot count 100uS correctly.
Why do I want to use C-code Timer?
When I use RCSwitch library with function micros() I have no problems with IDE code.
I didn't try to convert RCSwitch library to FC8 program as RCSwitch uses struct, etc.
However there are another program on internet about Manchester protocol (much easy to transform to FC8). And I did it. However the Timer1 component doesn't work.

Thanks.
Viktor

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi Chipfryer

Re: Enable IOC on D2 (or perhaps wait until high)

That is a problem as we deal with floating level of output of SYN470R Rf chip.
Signal is not clean and as I understood some programs will run a few cycles until the AGM output of SYN470R will go lower. I attached a very noisy RF 433.975 MHz signal. Note: this is not the output of SYN470R chip. It is recorded via mike audio signal from Yaesu Vx-6. Signal from SYN470R should be better. But I think this is the idea.

Re: enable a Timer Interrupt set at 350uS
I have tried to do that and failed as I have to read more about setting the Timer (and choosing which Timer to use, etc).

Syncronisation and Preamble
Correct me if I am wrong:
So far I see the problem in synchronisation.
Whatever I do, I cannot syncronise the signal from rxb12 receiver via D2 input.
If (and I couldn't do it so far) the synchronisation occur the FC8 program should wait even longer to let SYN470R chip AGC to stabilise. Only after the data frame can be received.
As I mentioned before, the RCSwitch Ard library does it without any problems.
Sampling
Please correct me, but I understand the sampling way as receiving TTL data by using 350uS clock. If clock runs the tick every 350mS the program should count raising/falling edges of coming TTL data, organise them into one bit, distinguish logic zero from logic one and save data to buffer.
Attachments
Packets-2.jpg
Packets-2.jpg (43.35 KiB) Viewed 77533 times

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by mnf »

Wow - that is a noisy signal! Do you have any filtering on the line?

I looked at the rc-switch library and it does use the pin change interrupt to record an array of timings.

This is a difficult way to debug code :-( - I wonder if there is a way you can record / send an actual signal and then a way we can 'play back' this signal to test?

Martin

chipfryer27
Valued Contributor
Valued Contributor
Posts: 618
Joined: Fri Jun 06, 2014 3:53 pm
Has thanked: 184 times
Been thanked: 195 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by chipfryer27 »

Hi

"Please correct me, but I understand the sampling way as receiving TTL data by using 350uS clock. If clock runs the tick every 350uS the program should count raising/falling edges of coming TTL data, organise them into one bit, distinguish logic zero from logic one and save data to buffer."

In sampling we aren't trying to detect a rising / falling edge, instead we just need to know that at the time of sampling is the signal high or low? If you look at the traces earlier, we sample within a time slot not at the edge. If say a one (High, High, High, Low) then at any point in each of the four time slots we should either return a High or a Low. This is the value we store for processing. Say we sampled in the middle of the time period:-

<-- 350uS --> <-- 350uS --> <-- 350uS --> <-- 350uS -->
< -- High -- > < -- High -- > < -- High -- > < -- Low -- >
Sampling in the middle of each slot would return 1-1-1-0

If each sample was stored in an array we could then have as say Address[1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0.........etc]

One we have received the entire message we can process and it would be easy to turn the captured data into bits (1-1-1-0 = 1 / 1-0-0-0 = 0). Ignoring the repeated message part for just now, the Preamble+Address+Data is 128 time slots = 128 samples. Each "bit" is four time slots in length so after processing we would be left with an 8-bit Preamble value, a 20-bit Address value and a 4-bit Data.

All processing takes place after capture, but it could start to process between samples if the processor was fast enough.

As Martin mentioned, it's more likely you will have a random high glitch (but could be low) and this would need to occur exactly when we sample to be noticed.

If we look at Preamble. It is a "trigger" to let us know we are about to receive a message and is high for one time slot followed by 31 x low time slots. Or so it should be in an ideal situation. Say you had noise for a few time slots making it random. Instead of h,l,l,l,l......etc you returned h,h,l,h,l...... would you reject this message entirely? It could well be that from time slot 31 (or 32 depending on when you started) you get data properly formatted making a valid address / data combination (each of the four samples that make up a bit MUST start with a High/1 and be either HHHl or HLLL). Preamble did it's job to allow circuits to settle. Of course we would expect the latter of the Preamble samples to be zero indicating that things had indeed settled. Processing a stream of samples may be a way to allow some random values into Preamble without compromising the entire transmission.

I haven't really played with the Nano and I too need to read up on it (a lot). I don't yet know if the Nano could actually do the required timing or sampling.

Would a comparator help on the input?

Regards

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »


What people write about the Automatic Gain Control in SYN470R chip


June 15, 2020, 05:41:18 pm--
My receivers all had the noise problem, no matter what voltage, pullup or power condensor I used. Even a speed change did not provide any improvement. For some reason, I took the power supply away from the arduino and connected it to a separate source (DC/DC converter). That resulted in a perfect pulse shape response at pulse speeds between 500 and 2 mSec.

https://www.eevblog.com/forum/rf-microw ... ver-noise/ --
The receiver output is a complete mess until a decent signal arrives, then it "cleans up" when the AGC kicks in and there is no problem decoding the output.
Before the AGC goes in "low gain"-mode there is just high frequency noise, which I dont understand that why does it have to be there why wont the schmitt trigger remove it.

September 06, 2016, 05:57:58 pm »
At the moment I am writing a code to sync to the low state after the preamble. I have implemented a simple glitch filter in the code, but still when I use an unmodified receiver, I dont get any good packets. I modified the receiver by replacing the resistor R12 (in schematic you posted ) to 500 Kohm resistor. Now I can run the receiver with 5 Volts, and get packets in about 60 % success rate.


RE: Would a comparator help on the input?
The comparator is part of SYN470R chip.

Re: High, Low, Error?

Synchronisation
The ideal synchronisation between the clock signal (read D2 timing) and the incoming to D2 TTL data is when the program can output logic Zero or One.

Not very ideal situation
D2 is not synchronised and distorted TTL signal is not square ended, but top rounded.
Error would be normal.

Error handling
It should be a mechanism or Error detection. If Errors detected program should go back to Idle state.
As you wrote: . Instead of h,l,l,l,l......etc you returned h,h,l,h,l...... would you reject this message entirely?

Preamble 350uS start pulse
I can guess, but the first 340uS preamble pulse would be lost easy in the noisy rounded ttl signal. We should let program to go to Error state, wait 350*32 + 24 bit ((4*350)*24) or wait 11200+(1400*24 +33600)=44800uS or 44-46mS.
After we try to find the 1st 350uS pulse again, if not, go to Error (wait 45mS) and try again.
As transmission repeats the code many times, we finally can find the Preamble and only after that save the data packet.
Attachments
Clock350+Pulse_Error.jpg
Clock350+Pulse_Error.jpg (60.66 KiB) Viewed 77499 times

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi

Re: if there is a way you can record / send an actual signal and then a way we can 'play back' this signal to test?

I think it is possible, but right now I don't have access to my scope.
If I do, I would connect the output of rxb12 433mHz receiver to my scope and record the packet.

chipfryer27
Valued Contributor
Valued Contributor
Posts: 618
Joined: Fri Jun 06, 2014 3:53 pm
Has thanked: 184 times
Been thanked: 195 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by chipfryer27 »

Hi
If I do, I would connect the output of rxb12 433mHz receiver to my scope and record the packet.
If you had a two channel scope it would be handy to see the output of the RF and the subsequent input to D2.

When the message is repeated, is it the Address + Data that is repeated or Preamble+Address+Data? If the former then you might never capture if you are expecting to capture a perfect Preamble. I would be surprised if you ever could see a perfect "first" Preamble as time is needed for things to settle.

You might be focussing too much on trying to get a perfect capture. The Preamble lasts 32 time slots (32x350uS = 11.2mS). If the incoming edge of the first time slot was used to wake things up so to speak, what happens further down the line at say t/s 24 onwards? Is it clearly defined Lows and a High at t/s 33? Basically I'm asking how long the Preamble takes to settle and I guess you won't know until you put your scope on things.

I think you are on the right track to first clean up the signal before looking at code.

Regards

chipfryer27
Valued Contributor
Valued Contributor
Posts: 618
Joined: Fri Jun 06, 2014 3:53 pm
Has thanked: 184 times
Been thanked: 195 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by chipfryer27 »

Hi

Sorry to be brief. I've just had a glance at the SYN470R datasheet and see that you can control many aspects including squelch and I also see the it has a Wake pin to signal the presence of a signal.

I thought perhaps the wake up pin could be useful but it activates if RF is present for 128 clock cycles. Assuming you are using a 6.7458MHz crystal then that would equate to 1/(6745800/256) x 128 = 4.86mS. As you only have a 0.35mS "high" it would be useless.

Have you tried adjusting squelch, mode and other parameters etc and if so does it make much of a difference? I assume your circuit is based around the example but adjusted for 433MHz.

I think you need to concentrate on this circuit just now before moving to code.

Regards

viktor_au
Posts: 342
Joined: Fri Jan 26, 2018 12:30 pm
Location: South Australia
Has thanked: 43 times
Been thanked: 60 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by viktor_au »

Hi

Re: Preamble+Address+Data

I think the packet repeated unchanged: Preamble+Address+Data.

SYN470R, 433MHz module

There are different modules with SYN470R chip.
Mine is the cheapest one and the outputs of data and squelch are connected or squelch is deactivated.

Re: need to concentrate on this circuit just now before moving to code
You are absolutely right, chipfryer. However many questions still do exist. Like - why when I use the same rxb12 board with SYN470R chip I have no problems and it works in Arduino IDE (with RCSWitch library) and doesnt work in FC8 program.
That is why I try to figure out what is the key point.
Is it that I try to catch the preamble High?
What if the preamble high already lost?
Should I wait for the frame/packet N3 or N4 to get synchronisation done and only after move to work with data part of this packet?
What is in the RCSwitch library that I don't have in FC8 code?
Let us have a look.

RCSwitch library has variables:
nReceivedDelay, nReceivedBitlength, nSeparationLimit = 4300, // A long stretch without signal level change occurred. This could be the gap between two transmission.
RCSWITCH_MAX_CHANGES 67 // Number of maximum high/Low changes per packet. We can handle up to (unsigned long) => 32 bit * 2 H/L changes per bit + 2 for sync
Buffer timings[],
That is how RCSwitch handles the packet:
//For protocols that start high, the sync period looks like
* ___
* | |____________|XXXXXXXXXXXXX|
* |-filtered out-|--1st dur--|--Start data--|
* * The 2nd saved duration starts the data
And so on...
----------------------------------

I was thinking...
What if I first check the lengh of the whole packet?
Say, I check the length/duration of packet N1, N2, N3.
Are they the same in milliseconds?
If they are:
try to catch the high pulses only.
If we have 4 pulses per bit, 8 bits in preamble and 24 bits in data, and if one pulse can have only one high (short or long doesnt matter now), we should count one high for preamble and 24 highs for data part. Total we should count 25*4 high's or 24*4 highs if preamble high is lost.
Will try to do that.

chipfryer27
Valued Contributor
Valued Contributor
Posts: 618
Joined: Fri Jun 06, 2014 3:53 pm
Has thanked: 184 times
Been thanked: 195 times
Contact:

Re: HC-12 433 mHz module + Ard + Kerui PIR

Post by chipfryer27 »

Hi Viktor

Quite by chance a little project has came along that might assist in a small way. A neighbour is building a garage and has obtained a 2nd hand roller shutter.This is mains powered with a key switch to raise / lower. No limit switches or control though.

They want to remote control it so I have suggested a module kit from a well known source. Operating at 433MHz the Rx unit is based on the 1527. Hopefully, if they go for the proposal I'll get a chance to poke around the receiver with a scope and if so it might throw some light.

Regards

Post Reply