• AVR Freaks

AnsweredHot!Guidance on 433MHz PIC16F Receiver Project

Page: < 123 Showing page 3 of 3
Author
btommo
Junior Member
  • Total Posts : 94
  • 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 : 1188
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
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
Junior Member
  • Total Posts : 94
  • 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 : 1188
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
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
Page: < 123 Showing page 3 of 3
Jump to:
© 2019 APG vNext Commercial Version 4.5