What you think those pedestrian crossing request buttons are actually connected to anything apart from the "wait" light that comes on?
Actually my current job is working with 100s of thousands of lines of code that is, in part, trying to figure out what to do when you press that button. It amazes me how much complexity you can put into a traffic light controller.
As this forum is to support and review this project, I have some questions:
1) Maybe I missed it somewhere, but was there a complete spec for this somewhere? Usually it is necessary to avoid something like this: http://www.jacobsen.no/anders/blog/archives/images/project.html
It should probably have current requirements as well as optional/future additions. Does it have a positive indicator that the button was pushed (lite a led above the switch)? For the future, how about an autodetect of the package, probably in a slot or box of some sort with a slow scan camera to make sure it is a package and not a beer can or pizza box.
2) Has a picture of the delivery spot been posted? Where is the package usually placed? on a step? under a bush? where someone can trip over it?
3) Has a test/delivery plan been made? What are the test and acceptance criteria? Will Micro have to travel to install/support? Who covers expenses?
4) I saw a picture of some hardware and a display. No schematic? Makes it tough to produce with the actual hardware if you are going to trace thru the rats nest of the prototype. Ok, maybe only mine are rats nests.
While Micro is going to do this, he should get the whole experience.
On a more practical note, does the XBEE transmit through the wall of a building or the internal walls inside? If the button is mounted outside, will the signal get to the receiver? It looked like they worked more line of sight.
The lack of a complete specification is really my fault - Micro and I have exchanged a few messages to cover the missing details. I've also provided him with more information about building layout and distance - and I've even tested the 60 mW XBee modules in this location with success. It's not line of sight, either - goes through a building (or around it, I guess).
Ken,
Sorry, I forgot to take the direct comms into account. Feedback seems to have slowed down. Micro must be almost done...
I'm impressed that the transmitter goes through the walls. May have to try some between my house and barn. The wife would like to check on things like electric fence on and some other stuff. It's about 500' or so. Looks like you can setup a multipoint network too. Interesting.
Take it slow.
Rich.
I havn't been updating latly because, yes, I am near completion. I'm just waiting until the parts come in so that I can solder and mount them. Ken said he forgot to ship me his composite display, and he's away from Parallax for now, so I still won't have it is finished condition until that comes in. Besides I will have to test the screen shutoff code, which is the only code that is NOT included in the current edition.
As for those of you worried about a "blind button", I've had that taken care of from the beginning of the code. The green LED that you can see in the picture will light for a few seconds after the pushbutton is pressed. If the acknowledgement byte isn't recieved, then the red LED will light, indicating that he needs to press it again.
Also, if the module is out of range, the screen will show an error message as it sends the "return signal" to test for the module once a minute. If the transmitter gets the "return signal" it promptly returns a positive byte. Literally, the "+" character. :-)
Ever since the first 2-3 days, the only thing I did for it was enhance the display a little with a black background instead of a blue (easy on the eyes) and different colored words in the "Package Received" message. The clock is still not an RTC, but a prop controlled one. This will be fixed when the package from Parallax arrives with my RTC. :-)
I've gotten my first work with an RTC just a few weeks ago, so this works out well, as I shouldn't have the same problems twice.
I got my package TODAY because they shipped it with overnight shipping!
I've already assembled the transmitter side, but have not drilled any holes in the acrylic, as I don't know if it would crack or not. I do have a button attached but it is just coming out of the PS/2 hole with wires.
I've attached a picture of the device and the screen, so you can see the new interface I've adapted.
@PJ Allen: I'll need to pick one of those up. Where can I get one?
@All: My current progress on the circuit - I now have the receiver partially built but every part is working as planned. I have the Xbee module and the RTC both on and fully working. I lost my 270 ohm resistor, and now I'll have to wait until I can find another one before I can get the video DAC built. I'll be adding the relay circuit now. I won't be able to work on this tomorrow because I will be gone all day, and most of Sunday. The circuit is nearly complete, and I'll release schematics Tuesday.
I'm guessing you should slowly hand drill the hole in the acryllic. If the bit grabs or seperates the acryllic without first cutting then it will crack because it is pulling the material apart rather than cutting it. You probably want to slowly drill and reverse slowly.
Hey Microcontrolled, all you need now is a big block of gray modelling clay with some wires stuck in it, and you can get a free tour of your local FBI office! :shocked:
I think you should put a Batman sticker on it and name it the "Bat Package Notifier". Then get the Propeller on the receiving end to make the Bat Phone sound when a package is delivered. :smilewinkgrin:
I have drilled acrylic with normal wood bits but using a drill press, going very slowly, and most importantly starting with a very small bit (1/16 or 3/32) and working up to the size I want in at most 1/8 inch increments.
To put small holes into acrylic, I use a hot soldering iron. The edges bubble up with the debris.
After it cools, take a razor blade and slice off the solidified mess. It makes a nice hole with no stress.
For bigger holes I use a CO2 laser, but I'm a little shaky and it's hard to hold the focus point well.
@micro,
One thing that i would add to this on the display side is when the system is triggered, the display color background flashes between two contrasting colors every second or half second, like blue/red or something to that effect. i dont know how close the proximity of people will be to the display, but it would make it very easily seen across the office. just an idea.
I'm coming in kinda late, but you might want to add a auditory indicator of some sort to. Perhaps you could use one of those 20 second voice modules they sell at radio shack and have it say a canned phrase like "Package has arrived"...Just a thought.
to drill acrylic place tape on both sides of the acrylic and drill slowly. laser cutter is ideal and I know parallax has one. Maybe you can beg to use it.
I use a small, hot wire to create the pilot hole, then drill slowly, sometimes stepping through sizes to get to the finished hole.
A piece of wood, cut to fit where needed, clamped to the acrylic makes a great support for the drill, and it prevents blow out on the exit side of the drilled hole.
I tested drilling though acrylic today, and I got a perfect hole using a small, normal drillbit and with the acrylic clamped to a piece of wood. (I'm doing this on the small "sample" piece of acrylic that they include with the kit), however, when I switched to a larger wood bit, it drilled but I didn't get as nice of a hole as I wanted. That and the drillbit heated up the acrylic to melting point, so that the "dust" melted and fused the little piece of acrylic to the drill bit, so now I have to find how to get THAT off....
@micro,
One thing i have done before is to use a hair dryer or heat gun to warm the acrylic or plastic up some to soften then drill slowly (a varible speed drill works great for this) and try to go through as slow as possible. Be careful not to heat the acrylic or plastic up too much or too fast as it will melt and/or discolor it. it took me a couple of tries using this method, but it works great once you get the hang of it. Hope this helps!
I tested drilling though acrylic today, and I got a perfect hole using a small, normal drillbit and with the acrylic clamped to a piece of wood. (I'm doing this on the small "sample" piece of acrylic that they include with the kit), however, when I switched to a larger wood bit, it drilled but I didn't get as nice of a hole as I wanted. That and the drillbit heated up the acrylic to melting point, so that the "dust" melted and fused the little piece of acrylic to the drill bit, so now I have to find how to get THAT off....
Are you using a hand drill or a drill press? I prefer to drill acrylic using a drill press. Feeding the bit slowly and backing it out often are much easier.
I recently got a small Proxxon drill press because I don't have room for a large one (even a bench mount). They aren't cheap, but I really like it.
I have fused melted plastic to bits before. I've had some success by using the same bit to drill a hole in scrap. This re-melted the plastic and I was able to remove it.
I am using a hand drill, as I don't have a drill press.
I was able to get it off and still get a descent hole, but I'll only use the method I used the first time on the real thing (slow, starting with a small bit).
Here are the requested schematics, attached, and I was able to get them done a day before the deadline I set. Keep in mind that these are not for the final documentation. These are first drafts only.
If the acknowledgement byte isn't recieved, then the red LED will light, indicating that he needs to press it again.
Microcontrolled, don't make the FedEx guy push the button a second time. It's unlikely he'll care if the transmission was received. The outside Propeller knows the button was pressed. Keep the light green and just keep resending the message every few seconds.
I get UPS almost everyday and I have a heck of a time getting the drivers to push my doorbell once. I know they wouldn't stick around to see if a red LED turned green.
I think you ought to have an AM PM indicator with your times. I doubt your using military style 24 hour time. You might want to ask Ken if he wants the seconds displayed. I personally like to see seconds but not everyone does.
You mentioned the xbees communicate every minute or so to make sure they are in range. You might not want to not give an error message ever time a reply isn't received. Have the Propeller try again a couple of times, wait a few minutes and try again and only after repeated and prolonged lack of communication give an error. What does the lack of communication hurt? An error message could be annoying especially when it doesn't really matter.
I thought I would explain "pilot hole", because the term may not be familiar. I have also heard this called the pre-hole, or pre-drill operation (hole).
Most drills have a small diameter non-cutting area, at the center. If it does cut, which many of the finer drills are machined to do at the tip to essentially start the drill working, it doesn't cut much, and on tenacious materials, will vibrate, chatter, grind, and generally be an annoyance. This is why a drill will not typically start where asked to, but rather where it eventually finds itself doing work on the material.
The forces involved can be significant enough to bend the drill in motion, even though the material to be worked is stationary, and the drill machine is also stationary. Chatter just happens, when that work to material ratio is too high.
The other thing that can happen is the "grab" where the material being worked actually forms a stress fault that runs roughly normal to the axis of the drill, (perpendicular). This can cause a overly large cut to occur, pulling the drill off axis, rendering the hole less round. Low drill speeds, plus excessive pressure along the axis of the drill can cause this to occur. Chips, tears, pulling of the drill away from the hole center, cracks, and chatter all are symptoms of this happening.
Higher cutting speeds, combined with a less aggressive drill pitch are good solutions, because the angle of the cut, in relation to the material is reduced, which limits many of these things, at the overall cost of efficiency, which can be compensated for with much higher cutting speeds than a hand held tool can deliver safely.
Most common drills I've seen have a fairly aggressive pitch, which warrants some care on brittle materials.
Performing that work in advance with either a small drill, or some operator, like the hot wire, is the "pilot hole". It serves to negate that very poor inner diameter cutting surface, which will center the drill, and maximize the work it is doing in relation to the size of the hole being drilled, which reduces the other effects considerably in most cases. If in doubt, a larger pilot hole is better than no pilot hole, so long as the material remains free of stress faults outside the intended hole diameter area.
A good pilot hole is equal to about 1/5" to 1/2" of the intended finished hole diameter being drilled. I generally shoot for 1/3 in most cases.
Generally, this is what all the really small sized drills in your set are for, unless you actually want those little holes!
Seconds are good to see the device is actually doing something. A blinky display element can do this as well.
Good call on the missed communication. If it were me, I would display the communication status, just so people can understand what is happening by watching the device. Communication that is consistent could be "good", "fair or moderate" works for some misses per hour, or other time unit, and poor where your code doesn't know, but is still seeing some communication. A long string of misses could be "not communicating".
A display area that says, "Communication Status: GOOD", could be entirely replaced with one that says, "NOT COMMUNICATING", for a great modal differentiator people will pick up on quickly. A few words can communicate a lot of things. Better to have them be the right things, and consistent than not; otherwise, the overall value of the display status communication is degraded overall.
Essentially, "Communication Status:" will imply some communication is happening. The colon tells them some data is to follow.
Now, the dilemma: If no data follows, what is happening? The user will wait, wondering if it takes time, or if it's really not talking at all. I see this kind of thing regularly and it always bothered me.
On the other hand, not displaying "Communication Status:" at all, replacing it with "NOT COMMUNICATING" is very clear. The user knows what they need to, and the first time they see it transition to the status message, the modal dynamic of the device state will be clear to them.
Short story, don't leave the communication status blank, if you choose to display something like that. Either it's communicating, and there is some coarse status level to communicate, or it's not communicating at all, leaving people clear as to what is happening, with a minimum of time and guessing required to understand what they are being told.
Be careful to separate status from diagnostics in these display messages too. Example might be "out of range" displayed for non-communication, when in fact the other device is actually powered down, or simply broken. Good attention to detail on these things results in robust devices that people can come to learn to understand, without frustration.
Often, diagnostic messages that really aren't, cause people to make assumptions that are unproductive.
Short story, tell them only what is known for sure.
If it's a one minute ping, you can think this through:
Initial power on state is NOT COMMUNICATING, until it actually does.
The long ping time makes a status characterization tough. I suppose I would go with good, then on a missed ping, degrade to poor, then NOT COMMUNICATING on the third ping, for the pings that happen quickly after power up, say 5 minutes. As the time goes by, scale that some, so people don't get into a panic on a missed ping, from time to time.
Say it makes three in a row, that's probably good, and missing the next one is fair, but making the one after that is good again.
Missing every other one is probably fair to poor, if two are missed.
...etc. Think about what you would want it to say, and then think of some ordinary persons reaction to it, and whatever you end up with probably will be solid.
I get UPS almost everyday and I have a heck of a time getting the drivers to push my doorbell once. I know they wouldn't stick around to see if a red LED turned green.
Delivery men are unique in that they move faster than electrons. By the time my bell actually rings here, the delivery man is halfway back to his truck.
I think the point is a good one, that the transmitting device should be responsible for retries, not the delivery man.
I haven't read through the whole thread, but one thing I would be concerned with is interference from other xbee devices, in particular at a location where xbee-related products are being developed (one wouldn't want a stray packet to be misinterpreted). If memory serves, the xbee has some encryption support and can use a key to secure the connection. Personally I haven't tried the encryption support yet, but I would think it to be a good idea.
As far as reliability/retransmission, one option is to forget about acks and go for a unidirectional solution. For example, configure the sender with a heartbeat to send a packet every 'n' seconds. Keep a monotonically-increasing button-push count on the transmitter side and increment that count every time a button press event occurred. Send that count to the receiver as the payload in the packets. If the receiver doesn't receive a packet within 'n' seconds, then it knows packets are being lost (at some 'm' lost packets, the receiver can get concerned and pop-up the 'connection lost' alert). As far as detecting button presses, the receiver need only note when the button-press count changed. One can even get really lazy and not even debounce the button.
The problem with acks is they often lead to some infinite logic recursion (how do I know that you received my packet? send an ack, of course. but, how do you know that I received your ack? how do I know that you know that I received your ack? how do you know that I know that you know that I received your ack? how do....)
Comments
What you think those pedestrian crossing request buttons are actually connected to anything apart from the "wait" light that comes on?
Actually my current job is working with 100s of thousands of lines of code that is, in part, trying to figure out what to do when you press that button. It amazes me how much complexity you can put into a traffic light controller.
1) Maybe I missed it somewhere, but was there a complete spec for this somewhere? Usually it is necessary to avoid something like this:
http://www.jacobsen.no/anders/blog/archives/images/project.html
It should probably have current requirements as well as optional/future additions. Does it have a positive indicator that the button was pushed (lite a led above the switch)? For the future, how about an autodetect of the package, probably in a slot or box of some sort with a slow scan camera to make sure it is a package and not a beer can or pizza box.
2) Has a picture of the delivery spot been posted? Where is the package usually placed? on a step? under a bush? where someone can trip over it?
3) Has a test/delivery plan been made? What are the test and acceptance criteria? Will Micro have to travel to install/support? Who covers expenses?
4) I saw a picture of some hardware and a display. No schematic? Makes it tough to produce with the actual hardware if you are going to trace thru the rats nest of the prototype. Ok, maybe only mine are rats nests.
While Micro is going to do this, he should get the whole experience.
On a more practical note, does the XBEE transmit through the wall of a building or the internal walls inside? If the button is mounted outside, will the signal get to the receiver? It looked like they worked more line of sight.
The lack of a complete specification is really my fault - Micro and I have exchanged a few messages to cover the missing details. I've also provided him with more information about building layout and distance - and I've even tested the 60 mW XBee modules in this location with success. It's not line of sight, either - goes through a building (or around it, I guess).
We will produce a schematic.
- Ken
Sorry, I forgot to take the direct comms into account. Feedback seems to have slowed down. Micro must be almost done...
I'm impressed that the transmitter goes through the walls. May have to try some between my house and barn. The wife would like to check on things like electric fence on and some other stuff. It's about 500' or so. Looks like you can setup a multipoint network too. Interesting.
Take it slow.
Rich.
As for those of you worried about a "blind button", I've had that taken care of from the beginning of the code. The green LED that you can see in the picture will light for a few seconds after the pushbutton is pressed. If the acknowledgement byte isn't recieved, then the red LED will light, indicating that he needs to press it again.
Also, if the module is out of range, the screen will show an error message as it sends the "return signal" to test for the module once a minute. If the transmitter gets the "return signal" it promptly returns a positive byte. Literally, the "+" character. :-)
Ever since the first 2-3 days, the only thing I did for it was enhance the display a little with a black background instead of a blue (easy on the eyes) and different colored words in the "Package Received" message. The clock is still not an RTC, but a prop controlled one. This will be fixed when the package from Parallax arrives with my RTC. :-)
I've gotten my first work with an RTC just a few weeks ago, so this works out well, as I shouldn't have the same problems twice.
I'll be working on a schematic shortly.
I got my package TODAY because they shipped it with overnight shipping!
I've already assembled the transmitter side, but have not drilled any holes in the acrylic, as I don't know if it would crack or not. I do have a button attached but it is just coming out of the PS/2 hole with wires.
I've attached a picture of the device and the screen, so you can see the new interface I've adapted.
There's a special drill bit for this: "point contact."
@All: My current progress on the circuit - I now have the receiver partially built but every part is working as planned. I have the Xbee module and the RTC both on and fully working. I lost my 270 ohm resistor, and now I'll have to wait until I can find another one before I can get the video DAC built. I'll be adding the relay circuit now. I won't be able to work on this tomorrow because I will be gone all day, and most of Sunday. The circuit is nearly complete, and I'll release schematics Tuesday.
I'm guessing you should slowly hand drill the hole in the acryllic. If the bit grabs or seperates the acryllic without first cutting then it will crack because it is pulling the material apart rather than cutting it. You probably want to slowly drill and reverse slowly.
My two thoughts. I haven't actually done it.
Chuck
I think you should put a Batman sticker on it and name it the "Bat Package Notifier". Then get the Propeller on the receiving end to make the Bat Phone sound when a package is delivered. :smilewinkgrin:
After it cools, take a razor blade and slice off the solidified mess. It makes a nice hole with no stress.
For bigger holes I use a CO2 laser, but I'm a little shaky and it's hard to hold the focus point well.
One thing that i would add to this on the display side is when the system is triggered, the display color background flashes between two contrasting colors every second or half second, like blue/red or something to that effect. i dont know how close the proximity of people will be to the display, but it would make it very easily seen across the office. just an idea.
A piece of wood, cut to fit where needed, clamped to the acrylic makes a great support for the drill, and it prevents blow out on the exit side of the drilled hole.
One thing i have done before is to use a hair dryer or heat gun to warm the acrylic or plastic up some to soften then drill slowly (a varible speed drill works great for this) and try to go through as slow as possible. Be careful not to heat the acrylic or plastic up too much or too fast as it will melt and/or discolor it. it took me a couple of tries using this method, but it works great once you get the hang of it. Hope this helps!
Are you using a hand drill or a drill press? I prefer to drill acrylic using a drill press. Feeding the bit slowly and backing it out often are much easier.
I recently got a small Proxxon drill press because I don't have room for a large one (even a bench mount). They aren't cheap, but I really like it.
I have fused melted plastic to bits before. I've had some success by using the same bit to drill a hole in scrap. This re-melted the plastic and I was able to remove it.
I was able to get it off and still get a descent hole, but I'll only use the method I used the first time on the real thing (slow, starting with a small bit).
Here are the requested schematics, attached, and I was able to get them done a day before the deadline I set. Keep in mind that these are not for the final documentation. These are first drafts only.
Microcontrolled, don't make the FedEx guy push the button a second time. It's unlikely he'll care if the transmission was received. The outside Propeller knows the button was pressed. Keep the light green and just keep resending the message every few seconds.
I get UPS almost everyday and I have a heck of a time getting the drivers to push my doorbell once. I know they wouldn't stick around to see if a red LED turned green.
Duane
I have a couple other suggestions.
I think you ought to have an AM PM indicator with your times. I doubt your using military style 24 hour time. You might want to ask Ken if he wants the seconds displayed. I personally like to see seconds but not everyone does.
You mentioned the xbees communicate every minute or so to make sure they are in range. You might not want to not give an error message ever time a reply isn't received. Have the Propeller try again a couple of times, wait a few minutes and try again and only after repeated and prolonged lack of communication give an error. What does the lack of communication hurt? An error message could be annoying especially when it doesn't really matter.
Duane
Most drills have a small diameter non-cutting area, at the center. If it does cut, which many of the finer drills are machined to do at the tip to essentially start the drill working, it doesn't cut much, and on tenacious materials, will vibrate, chatter, grind, and generally be an annoyance. This is why a drill will not typically start where asked to, but rather where it eventually finds itself doing work on the material.
The forces involved can be significant enough to bend the drill in motion, even though the material to be worked is stationary, and the drill machine is also stationary. Chatter just happens, when that work to material ratio is too high.
The other thing that can happen is the "grab" where the material being worked actually forms a stress fault that runs roughly normal to the axis of the drill, (perpendicular). This can cause a overly large cut to occur, pulling the drill off axis, rendering the hole less round. Low drill speeds, plus excessive pressure along the axis of the drill can cause this to occur. Chips, tears, pulling of the drill away from the hole center, cracks, and chatter all are symptoms of this happening.
Higher cutting speeds, combined with a less aggressive drill pitch are good solutions, because the angle of the cut, in relation to the material is reduced, which limits many of these things, at the overall cost of efficiency, which can be compensated for with much higher cutting speeds than a hand held tool can deliver safely.
Most common drills I've seen have a fairly aggressive pitch, which warrants some care on brittle materials.
Performing that work in advance with either a small drill, or some operator, like the hot wire, is the "pilot hole". It serves to negate that very poor inner diameter cutting surface, which will center the drill, and maximize the work it is doing in relation to the size of the hole being drilled, which reduces the other effects considerably in most cases. If in doubt, a larger pilot hole is better than no pilot hole, so long as the material remains free of stress faults outside the intended hole diameter area.
A good pilot hole is equal to about 1/5" to 1/2" of the intended finished hole diameter being drilled. I generally shoot for 1/3 in most cases.
Generally, this is what all the really small sized drills in your set are for, unless you actually want those little holes!
Good call on the missed communication. If it were me, I would display the communication status, just so people can understand what is happening by watching the device. Communication that is consistent could be "good", "fair or moderate" works for some misses per hour, or other time unit, and poor where your code doesn't know, but is still seeing some communication. A long string of misses could be "not communicating".
A display area that says, "Communication Status: GOOD", could be entirely replaced with one that says, "NOT COMMUNICATING", for a great modal differentiator people will pick up on quickly. A few words can communicate a lot of things. Better to have them be the right things, and consistent than not; otherwise, the overall value of the display status communication is degraded overall.
Essentially, "Communication Status:" will imply some communication is happening. The colon tells them some data is to follow.
Now, the dilemma: If no data follows, what is happening? The user will wait, wondering if it takes time, or if it's really not talking at all. I see this kind of thing regularly and it always bothered me.
On the other hand, not displaying "Communication Status:" at all, replacing it with "NOT COMMUNICATING" is very clear. The user knows what they need to, and the first time they see it transition to the status message, the modal dynamic of the device state will be clear to them.
Short story, don't leave the communication status blank, if you choose to display something like that. Either it's communicating, and there is some coarse status level to communicate, or it's not communicating at all, leaving people clear as to what is happening, with a minimum of time and guessing required to understand what they are being told.
Be careful to separate status from diagnostics in these display messages too. Example might be "out of range" displayed for non-communication, when in fact the other device is actually powered down, or simply broken. Good attention to detail on these things results in robust devices that people can come to learn to understand, without frustration.
Often, diagnostic messages that really aren't, cause people to make assumptions that are unproductive.
Short story, tell them only what is known for sure.
If it's a one minute ping, you can think this through:
Initial power on state is NOT COMMUNICATING, until it actually does.
The long ping time makes a status characterization tough. I suppose I would go with good, then on a missed ping, degrade to poor, then NOT COMMUNICATING on the third ping, for the pings that happen quickly after power up, say 5 minutes. As the time goes by, scale that some, so people don't get into a panic on a missed ping, from time to time.
Say it makes three in a row, that's probably good, and missing the next one is fair, but making the one after that is good again.
Missing every other one is probably fair to poor, if two are missed.
...etc. Think about what you would want it to say, and then think of some ordinary persons reaction to it, and whatever you end up with probably will be solid.
Delivery men are unique in that they move faster than electrons. By the time my bell actually rings here, the delivery man is halfway back to his truck.
I think the point is a good one, that the transmitting device should be responsible for retries, not the delivery man.
I haven't read through the whole thread, but one thing I would be concerned with is interference from other xbee devices, in particular at a location where xbee-related products are being developed (one wouldn't want a stray packet to be misinterpreted). If memory serves, the xbee has some encryption support and can use a key to secure the connection. Personally I haven't tried the encryption support yet, but I would think it to be a good idea.
As far as reliability/retransmission, one option is to forget about acks and go for a unidirectional solution. For example, configure the sender with a heartbeat to send a packet every 'n' seconds. Keep a monotonically-increasing button-push count on the transmitter side and increment that count every time a button press event occurred. Send that count to the receiver as the payload in the packets. If the receiver doesn't receive a packet within 'n' seconds, then it knows packets are being lost (at some 'm' lost packets, the receiver can get concerned and pop-up the 'connection lost' alert). As far as detecting button presses, the receiver need only note when the button-press count changed. One can even get really lazy and not even debounce the button.
The problem with acks is they often lead to some infinite logic recursion (how do I know that you received my packet? send an ack, of course. but, how do you know that I received your ack? how do I know that you know that I received your ack? how do you know that I know that you know that I received your ack? how do....)