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

chipfryer27
Valued Contributor
Valued Contributor
Posts: 617
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've never really used the Arduino family other than a Nano for some basic stuff.

In FC with Nano selected I looked at Interrupt on INT0 / INT1 which appear to have an interrupt frequency of 15Hz (roughly 66mS), which would mean it could miss an entire transmission. The IOC Ports appear to only be active or triggering on both edges. When looking at Timers I only saw prescaler options.

For Timer 2 (for example) I saw that I could select "Int on T0, +ve Edge" at 62500Hz so I assume I could use that pin (sampled every 16uS ?). Didn't see any way to set a timer interrupt at anything other prescale values so not sure how I could set an interrupt for every 350uS (for example).

Clearly I need to read up a bit on the Arduino / Nano devices.

Regards

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 »

As an aside - Jan and I worked on an IR remote decoder that used a similar message structure (although the timings are much different)

It might be possible to modify this code to work with this - the time handling will need some work...

See https://www.flowcode.co.uk/forums/viewt ... c&start=30

Martin

chipfryer27
Valued Contributor
Valued Contributor
Posts: 617
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 Martin

Thanks for the link, I'd forgotten all about that.

If I were using a PIC I could easily set an interrupt for 175 / 350uS even running at a lowly 8MHz (using Medelec35's spreadsheet it's dead easy to configure. As an aside didn't it become a component under Runtime? Can't find it now though).

It's quite possible that it can easily be done without resorting to "C", I just need to learn more (a LOT) about Nano's etc

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
Thank you for the link.

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 »

I am not sure how to run interrupt on Nano D2 input to check on 350uS if interrupt freq is 15Hz?
15 Hz = 66666uS
-------------------
Need to read again about mentioned by you about sampling...

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 »

About sampling
-----------------------
You have suggested:

For detecting a "0" (h - L - L - L)
Detect high (beginning of pulse). Time = 0
Wait 1/2 time period and sample (Time = 175uS). Value = 1
Wait time period and sample (Time = 525uS). Value = 0
Wait time period and sample (Time = 875uS). Value = 0
Wait time period and sample (Time = 1225uS). Value = 0
--------------------------------------
Can you please tell what is the best way to wait 175uS, 350uS, etc.
Should I use 16-bit timer to count microseconds?

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 »

We looked at a couple of ways of doing this:

1) Use a 'delay' icon (So if all delays are multiples of 350us - count the number of 175us delays occurring)
2) Use a timer - and start / stop the timer.

The code is all based on looking at the times at pin change however.

The interrupt on pin change (Arduino can do pin change - we did versions using this and only single direction for PIC) - one pulse followed by 31 'low pulses' is 'start' state.
Note that error handling becomes an issue - for example pin goes high / stays high or Pulse and then goes low and stays low (sensor broken or 'noise')
Times - 350us +/- an error margin (say 10%?)

It should be a fairly simple state machine:

This is my interpretation - using a 350us or multiple thereof pulse..
My reading is
Pulse then 31 x low (Start)
3 High 1 low = 1 bit
1 High 3 low = 0 bit
Stop after 24 bits

I've allowed a fairly wide margin of error on timings. I used a timer - this messes with UART - depending on Timer used, I've used a led display you'll probably need to change the output - this was what I used for IR testing.

Note - I don't actually test for high or low - but if the pin changes from low then it must have gone high - and vice versa - so a test for pin low as idle in main would suffice,

I don't have any hardware to test with.
HC12.fcfx
(24.72 KiB) Downloaded 135 times
Martin

chipfryer27
Valued Contributor
Valued Contributor
Posts: 617
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

In the Evil Lab today, which is freezing, I knocked up a generator using PIC16F1939 simply because it was in the multiprogrammer and connected to a Comboboard.

Four buttons:-
1) Sends a Preamble (1x h, 31 x l)
2) Sends a "1" (3 x h, 1 x l)
3) Send a "0" (1 x h, 3 x l)
4) Sends a transmission comprising of Preamble, address, data.

Did I mention Elsa wants to store her ice-cream in here? Luckily my collegue turned up with what loosely can be described as a jet-engine. Kerosene powered and attempts to fly off if not secured.... Soon had the place toasty, especially for me up in my Ivory Tower.

I set the address as 1010 1111 0000 1100 1001 with data as 1101.

Code is not complicated, very basic indeed, nothing fancy here. Simple delay for on/off times etc which would need to be tweaked to take into consideration the time taken to process code (you could calculate such but my excuse is that the grease lubricating my slide rule has frozen and I'm sticking to it...:) )

To send the transmission we need to send each bit at a time so we need to check the value and send the appropriate bit. I chose to send MSB first. Again not a fancy piece of code and more functional rather than an example of how to code so please feel free to make it better :)

To check things are working as I hoped, I added in a couple of calculations to reconstruct the address+data being sent, bit per bit. All good so far when simulating.

I have two pins active C0 and C1. C0 is the transmission output and C1 is a reference. The reference goes high at the beginning of any transmission and low once complete. This gives a handy frame of reference to measure against.

Unfortunately by now we had run out of jet-fuel so temperature was dropping rapidly....

Connecting an analyser to the pins the code worked pretty much as expected, but the expected tweaking of delays was affected by the rapid fluctuation in temprature (degrees per minute). You can see such in the attached traces. The difference in accuracy between working on "preamble" (button 1) to sending the complete transmission is a few microseconds.

Some analyser traces:-

Preamble.jpg
Preamble.jpg (40.94 KiB) Viewed 92606 times
Preamble (button-1).If you look at Ch1 (reference) you can see that instead of 11.2mS we are 3.7uS short. An hour or so earlier it was fractions of a uS out.

One.jpg
One.jpg (40.28 KiB) Viewed 92606 times
"1" (button-2). The high is 1.0488mS but earlier it was 1.050x. Again nothing but drift.

zero.jpg
zero.jpg (42.31 KiB) Viewed 92606 times
"0" (button-3). The "0" sends a few uS shy of 1.4mS due to temperature changes

Send_1.jpg
Send_1.jpg (39.84 KiB) Viewed 92606 times
Entire transmission of preamble, address and data which took 44.786mS to send which is 14uS short of calculated. Not too bad as I'm also keeping an eye out for polar bears.....

Send_2.jpg
Send_2.jpg (37.51 KiB) Viewed 92606 times
Preamble is 350uS high followed by lows, taking fractions of a uS off of target time for such (11.2mS)

The next two traces show sending a "1" at the beginning of the address and near the end of the transmission, out by fractions of a uS

Send_3.jpg
Send_3.jpg (37.11 KiB) Viewed 92606 times
Send_4.jpg
Send_4.jpg (37.88 KiB) Viewed 92606 times

The next two show "0" again at beginning and near end.

Send_5.jpg
Send_5.jpg (36.97 KiB) Viewed 92606 times
Send_6.jpg
Send_6.jpg (37.58 KiB) Viewed 92606 times

For my needs this is more than accurate enough, and I'll probably modify to repeat the address+data a further two times to further mimic the real transmission. Next I'll try and decode based on the above transmissions.

Regards
Attachments
Pulse_Gen_v8_1.fcfx
(25.88 KiB) Downloaded 138 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:

D2 pin change and slow interrupt

Post by viktor_au »

D2 pin change and slow interrupt

Hi
First of all thanks to mnf for time and support.

IN0 is too slow

HC-12.fcfx program uses (Nano) monitoring the D2 INT0 (Timer0) interrupt.
INT0 'ticks' 15Hz/Second or apprx 70mS (please correct me).
However coming from rxb12 433mHz receiver pack of pulses lengh = 350uS * 32 (preamble)=11200uS or apprx 11mS.
Plus 24-bit Data pack. Each bit has 4 pulses. 24*4=96. 96*350=33600uS or apprx 36mS.
Total packet length = 47mS.
As chipfrayer mentioned in his post:
Entire transmission of preamble, address and data which took 44.786mS to send which is 14uS short of calculated.
-----------------------------------------
It means that INT0 interrupt constantly misses not one packet, but 100 transmissions.
Looks like the interrupt handling should be changed.

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

Tx test/sim TTL signal

Post by viktor_au »

Tx test/sim TTL signal

Hello
Thank you chipfryer27 for spending so much time in the Evil Lab.

Where is Jockland?
Is it in Scotland?
No wonder it is so called there.
We have spring in South Australia now. A lot of storms, wind and rain.
I feel like I am in Scotland.
Back to Evil Lab project.

I don't have a Combo-board, however it was interesting to look at the scope diagrams of a different states of Tx transmission.
My interest right now is to find the Preamble during the Tx in the Kerui PIR packet.
If total length of Preamble = 11200uS.
If there will be no noise during Preamble part (from SYN470R chip) I can use Nano to get it.
But right now I cannot.

My testing program (based on mnf program HC12.fcfx) constantly in the error state of 'floating' output of SYN470R chip.
I am working on a new PCB for Nano + schmitt trigger to clean up the noise.
PS
Interesting to note, that RCSwitch library (IDE Arduino) works well.
I have to check this library and spend more time with it.

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

FC8 Timer component question

Post by viktor_au »

When I have to measure microseconds how good the Timer component is?
I noticed on forum that some people used a C-code.
Is it a way to do it?

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 »

I think the timer component should be accurate enough - I posted some code that used a high resolution timer (with a bit of C to decode the j1850 protocol (see viewtopic.php?f=6&t=21641&hilit=cobvert ... 331#p98331) but it's rather more complicated) but 350us is quite a long time when you're running along at 16MHz :-)

So - a couple of questions about the protocol.

Is the pin is pulled high (say for 'one') for 1050us - or does it pulse 350us high short low 350us high short low... - the interrupt will fire on each transition.
Is there some post-amble? Probably a 350us pulse - otherwise there is no end 'marker' Or at the end of a message (all data ends on a low) does it just stay at 0 and after 350us final low pulse assume we 'that's all folks'.

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

Re: j1850 protocol

I've read this post.

Before I move to C-code I would like to use the Timer component...
It works in simulation. However not in hardware.
-------------
The rxb12 433mHz receiver output of SYN470R Rf chip has apprx 2.4v output.
It is the result of Automatic Gain Controller.
RCSwitch library handles it, as it has some error correction mechanism in it.
But in FC8 programm the D2 pin on Nano constantly picks up this 2.4v as High.
Looks like I have to make a new PCB with the schmitt trigger.

After I fix the hardware I will move back to the protocol polishing.
Thanks

chipfryer27
Valued Contributor
Valued Contributor
Posts: 617
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

Yes, Jockland is colloquial for Scotland. It isn't that cold just now but as the Evil Lab is bereft of heating the insides are typically only a degree or two above outside temperature. In summer though, up in my Ivory Tower it can reach 30+C which is much more my liking.

From my understanding of 1527, the preamble/address/data are as described above, all pulse-width (with the address/data being sent three times). As far as I'm aware there are no stop bits. As I don't have Viktor's device to test with I can't say for certain, so I made a generator based on the information I have (still need to include repeating address+data) which should be accurate enough to test with.

I agree with Martin that 350uS is a long time for the Nano (running at 16MHz) so you should be able to do this with Timers. However the INT0/1 seem to only poll at 15Hz which means you could miss transmissions. Port IOC set to +ve trigger may be a better option or perhaps custom triggering?

If you get any spurious transmissions, then if you are timing between say rising edges then you could easily read incorrectly. This may or may not be a concern as it would depend on many factors we are unaware of.

I'll look at receiving and decoding signals I've generated.

Regards

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 »

I think the pin change can occur at >15Hz?

The 'info' at the bottom of the dialog is for 'Timer' interrupts and I think is just a red herring?

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 »

I got things to read and write.

I modded Iain's code slightly - to run on an ATTiny85 (it was to hand) as a transmitter - sending a number (incrementing) at 1s intervals. The chip I used is running at 16.5MHz (Digistump) - and timings were slightly fast using 'delays' when viewed on the 'scope.

I added a 'pulse' at the end as an end of data marker.

I changed the receive to put the data in the order received So MSB(23) -> LSB(0) whereas the correct order maybe LSB(16) .. MSB(23) then LSB(8)..MSB(15) which was the case for IR and 'loosened' the timings slightly.

I also moved to a Uno (but this is compatible with Nano) - stuck the Tiny on top and away it went. Note that UART seems okay with the timer set as is.
HC12 Transmit.fcfx
(13.94 KiB) Downloaded 144 times
HC12.fcfx
(23.05 KiB) Downloaded 127 times
If there is no 'EOD' marker - then we can bail out on receiving the final 0 or 1 initial pulse.
Due to confusion - I was sending the most significant 24 bits of a 32-bit integer - now fixed :)
Error handling is 'weak' and it can get stuck in an error state - resetting will clear this.

Martin

chipfryer27
Valued Contributor
Valued Contributor
Posts: 617
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

Looks good. I'll try and port to chips I have. Totally forgotten about the Timer component :)

Hopefully Viktor can try the Receive with his hardware.

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 »

Hello
Thank you guys for looking at this issue

I am in a motorhome (right now) 220 km away from Adelaide.
I don't have access to my scope, etc.
However after the last trip to Adelaide and a new PCB for Nano+rxb12 I can program it and test it.



Interrupt IOT to IOC
Port IOC set to +ve trigger may be a better option or perhaps custom triggering?
I moved from IOT to IOC to test it.

After I read (again) the RCSwitch library (Ard IDE library) I changed the INT0 to Interrupt On Change. But untill I clean up the signal from SYN470R Rf chip of rxb12 module I cannot move forward.
As correctly noted by chipfrayer the SYn470R has a very 'noisy' TTL signal and the way SYN470R Rf chip AGC block manipulates the output (which is another big issue) -> all are another factors.
Have to note that RCSwitch library handles that noise with ease and does the job.

About the TTL signal
As I don't have my scope I can only guess that the output from SYN470R Rf chip signal looks like the disturbed oval without any square edges. My program doesn't pick it up and cannot measure 350uS between the raising and falling edges.Because of the noisy TTL signal out of SYN470R I constantly see the faulse triggering (mostly when pulse duration < 350uS).

Questions
What is rcvd abbreviation?
Is it (one bit = 4 pulses) the state of one pulse?

State of the machine (change on any edge of Int)
Idle -> Start Timer1, go to Start
Start->Get from Timer1 duration in uS, if (.pulse >= 300) && (.pulse < 400), bit_n = 0, pulse_array values: 0,1,2 = 0, go to SOF
SOF(Preamble)-> if (.pulse >= 30 * 350) && (.pulse < 32 * 350) Go to Data
---------------------- etc
For some reason I don't see the Timer1 stops before state hit SOF state.
In the main loop the state of pinB5 is constantly put to zero. Why? Does it mess with the interrupt readings of pin B5?
I don't see the value of pulse reset to zero after reading.
Attachments
HC12_Rx_1.fcfx
(26.55 KiB) Downloaded 123 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,

Noise will certainly cause issues if it triggers an interrupt.
It would be difficult to modify the code to work on a single direction interrupt - the length of a 0 and 1 'bit' are the same - so if measuring from rise to rise the total time (4 x 350us) is the same for either value.

Pin B5 is just the inbuilt LED - I was setting it to 1 / 0 as a bit of debug (LED flashes on 'action'). Can safely be removed.

I don't think the timer will be stopped until END (or ERROR) - It's started on 'first pulse' when idle and then reset several times (reset at each interrupt - length of pulse read and then reset).

You need to add a delay in the if END part of main - if my theory is correct that there is an end pulse - the system must not return to idle until after input has returned to low (otherwise the end of EOD pulse will set state to START incorrectly). If there is not an end pulse - then need 'if pos == 23' in Read0 and Read1 cases after confirming pulse length. Alternatively - add some extra states to check for the presence of EOD pulse and only return END if found.

The IR data was transmitted as LSB .. MSB for bytes 0..3 (4 bytes in the case of IR) - this is easily accommodated - but depends on the message spec. The data was read into an array - because on IR bytes[0] and 2 and 1 and 3 were 'checksums'. The code can be modded to read to a single long value if it is just a 24 bit number. The transmitter does MSB -> LSB (bit 23 -> 0) and the receiver handles this case.

My test rig has now done 117 * 256 + 168 transfers :-)

Questions:
What is rcvd abbreviation?
- not sure rcvd is a 4 byte array to hold the received data (3 bytes would be enough here - 4 bytes was a legacy of my IR code) - stands for 'received'.

The interrupt handler - acts a state machine. On any interrupt in will just go through one path.

So - if state is IDLE - on interrupt it starts the timer, sets the state to START and returns to the 'main' loop which may or may not do something - here just testing if state = END. Note that the code does NOT goto start until the next interrupt when PinChange is called again.

State = START on an interrupt -> clears the current data and checks that a pulse (350us +/-) was received and sets state to SOF to look for a long low

State = SOF - interrupt - checks long low received (31 * 350us)
etc

Note that it never checks whether the pin is low or high (and would work equally well with an inverted signal) - it uses changes in pin state,

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 »

Thanks Martin

On Ard board LED B5 for debugging only: Understood
-------------
When I read the RCSwitch library I noted that after 1st high was detected system was waiting for the 2nd High.
Last edited by viktor_au on Tue Nov 22, 2022 4:43 am, edited 1 time in total.

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

Nano + RCSwitch

Post by viktor_au »

Hi
Will look at RCSwitch IDE library
Last edited by viktor_au on Wed Nov 23, 2022 9:05 am, edited 1 time in total.

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,

The Arduino library works in a slightly different way (albeit rather more complicated):

1) Record a list of pulses high/low and their lengths for complete message
2) Decode the list of pulses.

This means that multiple message protocols can be handled using a single data 'recorder' with a new protocol-decoder needed to handle each message format. This means that the same code can handle IR and RF transmissions in a variety of formats - the state machine approach is so simple however, that I'm not sure this is a useful tradeoff.
The protocol describes the length of pulses and also the bit 'order'.

I think it uses the same technique to measure pulse lengths (pin change interrupts) - however it would be possible to record them using a 'busy' wait -

while(pin == HIGH) increment timer.
Record time
while(pin = LOW) increment timer.
record low time.

There are issues with both approaches. Particularly 'noise' which can trigger a pin change.

The interrupt technique is (IMO) better - it means that the MCU can handle other tasks and receive signals at any time - the main program just needs to check if a signal has been received at regular intervals. However - I used the 'busy' wait with the j1850 decoder - and it worked ok - main loop needs to watch for the initial pin-change before moving to receive.

Note that the state machine can handle various improvements (for example a time out can be added fairly easily - by replacing the timer component with a timer interrupt - I have some code that does this if required - it did mess up UART though). It can also return partial messages if required - though whether this is actually useful is dependent on message content.




Did you get the code I posted to return anything? (See note above about adding a delay - or a check that pin is LOW before setting state to idle) - One suggestion is to output 'pos' in the main loop and see if this changes.

It should be possible to run the code in simulation - using two copies of FC running at the same time (which I've not tried) - I did it with the IR code by writing a transmit function that toggled the interrupt pin but also passed the pulse length to the interrupt routine (as timings aren't going to be right) which might help??

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 »

Just had an idea for making this more 'robust' concerning noise.

All the pulses are fairly long (350us+) - so if the pulse is less than a 'threshold' value (say 50us or 10us) then ignore it. This is easily done near the start of pin change with

if pulse < threshold error_count = error_count + 1 else 'handle as before'

The number of errors can be used to give the signal a 'rating'

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

Re: Did you get the code I posted to return anything?
I have to change pinB5 to pinD2 in your code as D2 is connected to output of SYN470R Rf chip.
I run this code on Nano a few times by using the Tx remote controller with 24-bit code (1527 protocol). No return.

Re: It should be possible to run the code in simulation
Sure. I have to wait for the opportunity to do that.

About the RCSwitch library.
I works well with the noisy ttl signal from SYN470R Rf chip.
That is why I am trying to understand how it works.

Preamble
I think I should stop trying to get the data block and instead concentrate on the Preamble stage.
If I can manage get the Preamble, that would be a success.

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'm not sure what you mean by " I have to change pin B5 to pin d2" . D2 is the interrupt pin for int0 (it is fixed) and we must not write to it - if a write changes the value it will fire the interrupt which is not what we want. It should be connected to the input from the sensor.

Can you post your code and I'll take a look - I'll also try and post a version with the noise reduction as above...

Martin

Post Reply