• AVR Freaks

AnsweredHot!Guidance on 433MHz PIC16F Receiver Project

Page: < 123 Showing page 3 of 3
Author
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/07/17 10:17:25 (permalink)
0
I managed to change it to an array to store values and check against the remote_code and store if in the programming state, using the array method saved just over 15% program memory. Next thing i'm aiming to do is generate a 'scramble' value for when the remotes are erased, I'm thinking use a calculation of a combination of the stored remote values and previous scramble code genated from previous erase... Unless there's a way to generate a real random number?
post edited by btommo - 2019/07/17 10:32:16
#41
pcbbc
Super Member
  • Total Posts : 1700
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: online
Re: Guidance on 433MHz PIC16F Receiver Project 2019/07/17 11:13:06 (permalink)
0
btommo
I managed to change it to an array to store values and check against the remote_code and store if in the programming state, using the array method saved just over 15% program memory. Next thing i'm aiming to do is generate a 'scramble' value for when the remotes are erased, I'm thinking use a calculation of a combination of the stored remote values and previous scramble code genated from previous erase... Unless there's a way to generate a real random number?

For an erased remote you are trying to replace it's code with the 'scramble value'?  But there is a slim chance that someone has a remote with that code, is there not?
 
I really don't understand why you think you need a 'scramable value' for this.  Store a flag which says if each element in the array is valid or not.  Set the flag to valid when you program a remote in that slot, clear it (and delete the code) when you erase.
 
Heck, you have a 32-bit integer as the remote code, and are only using 25 bits of it.  You can use one of the bits as the flag (let's say bit 31), or a special value.  e.g. 0xFFFFFFFF which cannot represent a valid code as you are only using the lower 25 bits.
#42
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/07/17 11:39:47 (permalink)
0
That makes more sense and saves the need for an extra uint32_t which I was initially planning to do which would be a waste, I'll just put an extra check for default value when it checks for the valid code.

I think I was over thinking it.
post edited by btommo - 2019/07/17 11:57:56
#43
pcbbc
Super Member
  • Total Posts : 1700
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: online
Re: Guidance on 433MHz PIC16F Receiver Project 2019/07/17 14:11:43 (permalink) ☼ Best Answerby btommo 2019/07/19 06:45:17
0
If you use 0xFFFFFFFF it can never match a valid remote because the top 7 unused bits will always be zeros in a valid code. So you do not even need to check for the default value, it will just fail to match if any valid remote is compared against 0xFFFFFFFF.
#44
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/11 14:02:29 (permalink)
0
Apologies to reopen this old Post but I was wondering, I have the ability to make receiver code for this but what about transmitting, especially signals individual to each unit, can we brain storm ideas on this?
#45
pcbbc
Super Member
  • Total Posts : 1700
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: online
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/11 20:42:58 (permalink)
0
What are you transmitting to? The keys fobs you have can only transmit, they are incapable of receiving a signal.
 
You can roll your own transmit and receive using OOK transmission protocol and the very simple 433 radio transceiver modules if you want,
 
But for anything at all complicated look at the Nordic nRF24 series and the various clones. These offload the protocol engine for the OTA communication onto a separate chip. So you get all the benefits of address checking, retrying packets, collision detection, acknowledgments, CRC generation and more handled for you.
#46
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 03:28:04 (permalink)
0
I'm kinda planning to build units that communication with each other, one unit would have inputs then send a signal similar to  to another unit which would trigger outputs based on the received signal but each kit would need to be paired and each transmitter would have to have it's own identity shown in the sent signal so the receiver can only act with the transmitter it's paired with similar to the key fobs, rather than each transmitter being programmed with the same identity. Is it possible for each transmitter to have seperate identities but loaded with the same .hex file?
 
I'll look at the series you mention.
#47
pcbbc
Super Member
  • Total Posts : 1700
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: online
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 03:48:07 (permalink)
+1 (1)
btommoIs it possible for each transmitter to have separate identities but loaded with the same .hex file?



Sure.
 
You just need some way to set the transmitters ID.  Be that via DIP switches, programmed into the EEPOM somehow, etc.
#48
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 04:17:41 (permalink)
0
But for mass production of units would this not be an issue? Can EEPROM data be changed while using the same .hex file?(may be a silly question sorry)
 
I've opened one of the keyfobs and seems only to have a couple of push buttons for lock/unlock an LED, a few passive, transistors, a single SOIC8 and a 433 MHz crystal and a battery on the back. Would they program each IC individually with a different .hex? 
#49
pcbbc
Super Member
  • Total Posts : 1700
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: online
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 05:13:53 (permalink)
+2 (2)
btommoI've opened one of the keyfobs and seems only to have a couple of push buttons for lock/unlock an LED, a few passive, transistors, a single SOIC8 and a 433 MHz crystal and a battery on the back. Would they program each IC individually with a different .hex?



Usually not a different hex.  When programming you'd just write some different EEPROM data.
 
Just the same in mass production of all consumer electronics for serial numbers, region specific configuration, etc.
You can also usually get the chip manufacturer to do this programming for you if you choose (at a price of course) and are ordering in bulk.  That way you don't have to do any user programming at all.  They'll also do things like laser etch your own custom logos or chip numbers onto the packages for you.
 
Also some PIC devices have a unique ID programmed into them from the factory already.  So you could use that to produce a semi-random initial value for the ID.
 
If the chip is a custom chip designed for this sole purpose which it may very well be (i.e. not a microprocessor) then the ID will be burnt in via the mask ROM when the chips are manufactured.  Each location on the wafer has a different ID and then there are many thousands of dies on each wafer.  So more than enough to cover every permutation of ID for say a 16 bit (65K permutation) key fob.  Or if you need a genuinely unique ID for each and every chip, then the next wafer can have a incremental wafer serial number.
 
Microchip IDs that are burn in via the mask ROM consist of various details such as the X,Y location of the chip on the die, the production facility and wafer serial number.
#50
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 05:38:28 (permalink)
0
How would I obtain the ID programmed into the PICs from the Factory? Does PIC16F1823 have separate IDs? as you mention some do. Could go the program house route and just set a known ID for testing purposes.
 
Does MPLAB IPE have the capability to do this? Just looked now, is it to do with the SQTP settings? If so how random is the "random" setting, would it be random from one session to another?
 
post edited by btommo - 2019/12/12 05:41:10
#51
pcbbc
Super Member
  • Total Posts : 1700
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: online
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 07:09:43 (permalink)
+1 (1)
btommoHow would I obtain the ID programmed into the PICs from the Factory?

Actually looking at the FAQ I can't immediately see how it is possible.  But it seems like a common enough request that it must be doable somehow.  But I haven't used their service so I can't say for certain...
 
Does PIC16F1823 have separate IDs? as you mention some do. Could go the program house route and just set a known ID for testing purposes.

3 words of User ID
1 word Device ID / Revision ID
See 11.5 User ID, Device ID and Configuration Word Access in the EEPROM section.
 
Device ID / Revision ID are used by microchip to indicate what chip it is, and the silicon revision.
User ID is for your own use, but as I said - no idea if their programming service can program it individually.
 
Does MPLAB IPE have the capability to do this? Just looked now, is it to do with the SQTP settings? If so how random is the "random" setting, would it be random from one session to another?

That will get you some random data each time you program the chip.
I think you can assume that it is random enough such that it will not generate two values the same as long as the key size is sufficiently large.  128-bit GUIDs work that way and the chances of a collision are infinitesimally small so as to be entirely negligable.
But if you need 100% guaranteed unique, but with only a short key length, then an incrementing serial is the way to go.
#52
Gort2015
Klaatu Barada Nikto
  • Total Posts : 3950
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 08:14:32 (permalink)
0
The advantage of Nordic nRF24 (2.4GHz) is that the signal will go through walls quite easy where as 433Mhz will not.
Without an external antenna the results are still good.
 
How many devices do you have?
 
 
 
 
 

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#53
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 08:25:17 (permalink)
0
@Pcbbc:
I'll try the different methods of generating the random bytes.
 
@Gort:
The new project is automotive based with both transmitter and receiver on the same vehicle. With the OOK fobs and receivers I have been using for the project this started with I've generally had a lot of success testing through walls without an antenna and at quite a big distance with an antenna but I did start with cheap 433MHz RF receivers "RF-5V but switched to "RXB12" using a SYN470R which was a big improvement.
post edited by btommo - 2019/12/12 09:49:30
#54
Gort2015
Klaatu Barada Nikto
  • Total Posts : 3950
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 09:48:15 (permalink)
0
I always thought that you needed to calculate the antenna size at 433MHz.
Now it's on the board.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#55
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 13:54:50 (permalink)
0
I got the antenna off a relay module that was purchased that used the RXB12 receiver circuit as needed to use same kind of remotes for a project
#56
Gort2015
Klaatu Barada Nikto
  • Total Posts : 3950
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 14:20:15 (permalink)
0
Seen them on ebay, the antenna is the underside of the board.
I've done the calculations but I think I did not use the correct material.  I used a pic10F to decode and it was kept busy then it would interrupt when data was ready.
 
I should used a decoder chip but then decided that nRF24 chips were better.

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#57
btommo
Senior Member
  • Total Posts : 136
  • Reward points : 0
  • Joined: 2017/07/07 02:59:33
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 15:17:42 (permalink)
0
I'm not sure what material the wire is but I'll check a known single core wire of same length tomorrow just to know if that's an issue.

I got my modules from Alibaba/express and weren't expensive at all. The SYN470R is an ASK/OOK receiver that doesn't need manual tuning and seemed to perform better than the generic 433MHz receivers.

Which nrf24 chip/module do you use?
post edited by btommo - 2019/12/12 15:21:36
#58
Gort2015
Klaatu Barada Nikto
  • Total Posts : 3950
  • Reward points : 0
  • Joined: 2015/04/30 10:49:57
  • Location: 0
  • Status: offline
Re: Guidance on 433MHz PIC16F Receiver Project 2019/12/12 16:45:32 (permalink)
+1 (1)
nRF24L01+
 

MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
https://www.youtube.com/watch?v=Iu1qa8N2ID0
+ ST:Continues, "What Ships are Made for", Q's back.
#59
Page: < 123 Showing page 3 of 3
Jump to:
© 2020 APG vNext Commercial Version 4.5