I haven't used the SX in a while, but I always used OSCXT1 in the DEVICE statement for a 4MHz resonator. According to the spec sheet OSCHS1 should work, but you may want to try some of the other oscillator settings.
Dave -- yes, I thought about that. That's why I'm going to have to him clock the project from the Key until everything is working right, then we'll get his resonator settings locked down. In my experience, spec "high speed" resonators with proper capacitance and load resistors will work with slightly lower OSC settings; in my practical experience a notch or two higher often solves clock problems on breadboard setups.
Dillon -- try the attached SX/B file (this should compile in your older 1.5x SX/B). The leds should behave exactly the same -- each in turn, 1/4 second on, 1/4 second off, over and over.
Then, if you could do me the favor of posting the .SRC file output by your installation of the SX IDE and SX/B; I just want to compare the changes in the PULSIN assembly generated by 1.5x against my installation of 2.x.
Awesome. OK, try this -- same setup. You should see leds light up one after another -- for 1/2 second each -- then it will try to read the message from the detector, and see if you either get:
- correct LEDs lighting up for correct message(s)
- or, LEDs that seem to maybe display an 8 bit message if there aren't too many zeros (this would be 1 second of the lower nibble on all 4 LEDs, then 1 second all off, then 1 second showing the upper nibble on all 4 leds, then all off for 1 second, then the next message would try to be captured
- nothing or ???
Also, regardless of outcome, attach the .SRC file generated by your compiler.
Here is what happened. I did RUN the program, and all the LED's lit up, one after another, for one loop, then stopped, so one pass through. I power cycled the unit and the same pattern occurred. The LED's are then static afterwards. I have attached the .SRC file.
Also, I tried running an 8-bit message and no results occurred.
It should only show the "startup" pattern once, then it should be looking for low pulsetrains on the SignalDetect pin. The detector is hooked up, you flashed a code at it, etc?
Try the attached. This isn't much different, but has a very clear startup sequence and I made it easier to read a non-parsed message on the LEDs if a message comes through. Run it via "RUN" with no resonator, leave the SX-Key connected. After the startup sequence, try to trigger your detector with message (a key fob?).
Here is how it should behave:
- on reset/powerup there is an LED display sequence that is only shown once
1. all the LEDs come on for 1/2 second, then all off for 1/2 second
2. then each LED in turn, on for 1/2 second, then off for 1/2 second
- then all LEDs should go dark unless a message is properly parsed.
1. if the message is one of your key four messages, the appropriate LED should light and stay lit until a different message comes in
2. if the message is received, but is not matched, then the byte received will be shown on the LEDs as follows:
a. all LEDs blink ONCE for about 1/2 second to "announce" the lower nibble (bits 0..3). Bit 0 will be on RB.1, Bit 1 on RB.2, etc.
b. the nibble is shown for 2 seconds (remember a nibble of "%0000" would be all leds off, hence the need to "announce the nibble")
c. all LEDs then blink TWICE "announce" the upper nibble (bits 4..7). Again, Bit 4 would be on RB.1, Bit5 on RB.2, etc.
d. the nibble is shown for 2 seconds
Repeat.
If this doesn't work, we'll try a version measuring high going pulses, but your trace clearly shows low going pulses.
The behavior is correct for the powerup/reset (all LED's light up for 1/2 sec, then each LED in turn lights up for 1/2 second).
I triggered each message (lock, unlock, trunk, panic) and no LED activity was seen. I have the oscilloscope hooked up and we see the signal travel across just as verification.
Unfortunately the same result. Before I got the other post, I tried changing the ERRORMARGIN from CON 10 to CON 15. Nothing transpired from that change.
I then ran the 08 version, and got the LEDs to all light up at first, then each LED turns off/on, then all LEDs go off. I tried to trigger each message and nothing occurred. I have attached the .SRC file for the 08 version.
OK, try this one. If this doesn't give you activity upon receipt of messages, then I'll post a version that only tries to catch the start bit and see if we can make some progress.
OK, try each of the attached. These just check for a valid start bit. If a valid start bit comes through, all LEDs light up and then the program halts (the same start-up sequence will display once on reset, as before).
Man, still nothing . We still get the LED startup routine (all LEDs light up for 1/2 second, then each for 1/2 second). But everytime I send a message (lock, unlock, etc.) still no LEDs light up. I attached the .SRC files for both the 10A and 10B versions. Many thanks for your persistance efforts Zoot.
This one checks for any single valid bit and lights led 1, 2, 3 depending on what kind of bit was received (start, one, zero). Then the program halts. If it lights an LED (after the startup sequence, let me know which one lit, and which version you used A or . Try these and let me know what happens.
My apologies for the late response. Meetings consumed most of my day. I tried both 11A & 11B and got the same response. The startup routine would run (all LEDs blink and then each LED blinks once in a pattern), but no LED response when I would send a message (lock, unlock, etc.) I'm stymied. I checked with another engineer to make sure the hardware is correct and he said it looked good. I swapped SX28 chips and ran 11A & 11B again and still the same results. I have attached the .SRC files.
All right. I think I'll post some code (later this evening or possibly tomorrow morning) that outputs the input signal to a pin. You should be able to check the input pin (detector) and the output pin on the scope and they should match (though the output pin should lag a bit). I'll also have a long pause or a break after a few pulse captures so you can debug and see what values you are actually getting. I'm really suprised none of the leds lit for pulse captures on the last test -- the margin of error is really high, and one version captures low pulses, the other high pulses, so it seems you should have gotten something.
Dillon -- there are two files in the attached archive. These are tests so we can see where this is failing (hopefully).
Note that both files define pin RB.7 as an output "test pin", though right now only #12 uses it.
Run these with no resonator, clocked by the key. Both show the same startup sequence for the LEDs as earlier versions.
#12: use RUN -- this program just outputs the signal detect pin onto the test pin. If you can, hook up a channel on your 'scope to the TestPin and a channel right to the input pin (RB.3). Use the fob and on your scope both channels should be essentially identical (technically, the output pin will lag by a 1/4 microsecond or so, but you won't see that difference at your 10ms scale). If this is the case, then we know the input pin is being "read" properly. If not, then we have a problem.
#13: use DEBUG -- if the results from #12 are OK, then this program just does a continous pulsin capture, without parsing it. The pulseDur is set up as a watch variable so you can halt the program. If that works OK, then #13, run in "DEBUG" will let you see the captured value of pulseDur. If you see all "grayed out" buttons in your debugger, then you have a bad or dirty connection to the key. You can optionally comment out the BREAK in the test area if you want the program to halt when/if a pulse is captured. Otherwise, you will want to hit STOP in the debugger occasionally to be able to read the watched variable value. If this works, then report some of the values you get for the pulsedur, so we can see if they are remotely in the zone. If you get no pulse durations (0 value in the watchlist), then we'll try capturing high pulses.
Does that make sense? If not, hit me up w/questions.
#12 - Ok, I ran #12 using RUN (no resonator, clocked by the key). I hooked up a channel to RB.7 & RB.3. I did get a signal from RB.7 but not RB.3. I also hooked up a channel to RB.7 and RA.3 and got two separate signals.
#13 - I could not get the debugger to work. I did DEBUG the program and still have grayed out buttons. I tried swapping out SX-Keys, changing wiring, cleaning leads, but still nothing. I also commented out the BREAk, and nothing transpired. I have attached a "printscreen" of the debugger, and the .SRC files for #12 & #13.
If I missed something, or there is something else I can do on this, please let me know,
I'm looking at your files now. Sorry, in my text in my last post I mistakenly wrote "RB.3" for the input pin when I should have written "RA.3". When you scoped RB.7 and RA.3 were the two traces essentially identical?
Dillon -- the grayed out debug buttons in your screen grab are problematic. This is usually indicative of a bad or dirty connection (FYI -- you may have no problem programming an SX with a "dirty" connection, but the timing requirements for debugging will fail).
Can you post a pic of your current breadboard setup?
Dillon -- also, just for grins, try the attached. I would expect this to fail, but if it doesn't we may have learned something. This is the "normal" program -- it should light up one of the 4 leds when it receives when of your 4 special messages or will show the two nibbles of a message received if it's any other combination. However this clocks at 20mhz. You will need to clock it from the Key (use RUN).
My instincts are still that there is a clocking problem -- perhaps bad connection from the key, or the breadboard setup won't support the resonator. That is the simplest explanation for why the program essentially works, but doesn't correctly capture the pulse durations. Would also explain debugging problems. But the margin of error is high enough that even with a clock out of spec, I would still think some messages would get captured.
Thank you for your input on troubleshooting the breadboard and SX-Key connector. I think I'm going to put the components on another breadboard and clean the SX-Key again best I can.
For #14, I did RUN the program and got some responses which was great to see. The typical results I get (when I press any button such as lock, unlock, etc.) are it lights up all four LEDs, and will either just do that once, or will light up all four LEDs again and then light up two LEDs, and then they timeout. Also, when I press the Panic button (value of "10111011") there is a constant case where all LED's light up, then immediately after, it just lights up the correct LED (blue) for about 3 seconds. I have done it 10 times and I get the same results.
I have attached the .SRC file for #14.
Also, I do have two questions I would like to ask of you off the forum. Do you have a preferred e-mail address I can contact you at? Would the e-mail address that is near the top of the code you have supplied be ok to reach you at?
For #14, I did RUN the program and got some responses which was great to see. The typical results I get (when I press any button such as lock, unlock, etc.) are it lights up all four LEDs, and will either just do that once, or will light up all four LEDs again and then light up two LEDs, and then they timeout. Also, when I press the Panic button (value of "10111011") there is a constant case where all LED's light up, then immediately after, it just lights up the correct LED (blue) for about 3 seconds. I have done it 10 times and I get the same results.
This is probably showing the upper and lower nibbles. The fact that is might be the "correct" LED on one of the nibbles is coincidental.
The case where you had 4 leds may have been a byte of %00001111 or %11110000.
If one of your special messages is not parsed and captured, any other message should make the following happen:
- all LEDs blink once for a second
- then 4 bits of the message are displayed (all leds dark = %0000; all leds lit = %1111, etc)
- then all LEDs blink twice for a second
- then the other 4 bits of the message are displayed
Sounds like progress, though, as you would only get LEDs lit if you correctly get 8 bits plus a start bit. I'll see if I can post some variations to try out before I take off in an hour or so for the afternoon.
Comments
Then, if you could do me the favor of posting the .SRC file output by your installation of the SX IDE and SX/B; I just want to compare the changes in the PULSIN assembly generated by 1.5x against my installation of 2.x.
- correct LEDs lighting up for correct message(s)
- or, LEDs that seem to maybe display an 8 bit message if there aren't too many zeros (this would be 1 second of the lower nibble on all 4 LEDs, then 1 second all off, then 1 second showing the upper nibble on all 4 leds, then all off for 1 second, then the next message would try to be captured
- nothing or ???
Also, regardless of outcome, attach the .SRC file generated by your compiler.
Also, I tried running an 8-bit message and no results occurred.
Here is how it should behave:
- on reset/powerup there is an LED display sequence that is only shown once
1. all the LEDs come on for 1/2 second, then all off for 1/2 second
2. then each LED in turn, on for 1/2 second, then off for 1/2 second
- then all LEDs should go dark unless a message is properly parsed.
1. if the message is one of your key four messages, the appropriate LED should light and stay lit until a different message comes in
2. if the message is received, but is not matched, then the byte received will be shown on the LEDs as follows:
a. all LEDs blink ONCE for about 1/2 second to "announce" the lower nibble (bits 0..3). Bit 0 will be on RB.1, Bit 1 on RB.2, etc.
b. the nibble is shown for 2 seconds (remember a nibble of "%0000" would be all leds off, hence the need to "announce the nibble")
c. all LEDs then blink TWICE "announce" the upper nibble (bits 4..7). Again, Bit 4 would be on RB.1, Bit5 on RB.2, etc.
d. the nibble is shown for 2 seconds
Repeat.
If this doesn't work, we'll try a version measuring high going pulses, but your trace clearly shows low going pulses.
First, you are correct about the key fob.
The behavior is correct for the powerup/reset (all LED's light up for 1/2 sec, then each LED in turn lights up for 1/2 second).
I triggered each message (lock, unlock, trunk, panic) and no LED activity was seen. I have the oscilloscope hooked up and we see the signal travel across just as verification.
I have attached the .SRC file.
As always, thank you for your help.
to
and rerun it.
Post the output .src file if you don't mind.
I then ran the 08 version, and got the LEDs to all light up at first, then each LED turns off/on, then all LEDs go off. I tried to trigger each message and nothing occurred. I have attached the .SRC file for the 08 version.
Still no activity from receipt of messages. I did power cycle the unit and same results. I have attached the .SRC file for the 09 version. Thank you.
OK, try each of the attached. These just check for a valid start bit. If a valid start bit comes through, all LEDs light up and then the program halts (the same start-up sequence will display once on reset, as before).
This one checks for any single valid bit and lights led 1, 2, 3 depending on what kind of bit was received (start, one, zero). Then the program halts. If it lights an LED (after the startup sequence, let me know which one lit, and which version you used A or
My apologies for the late response. Meetings consumed most of my day. I tried both 11A & 11B and got the same response. The startup routine would run (all LEDs blink and then each LED blinks once in a pattern), but no LED response when I would send a message (lock, unlock, etc.) I'm stymied. I checked with another engineer to make sure the hardware is correct and he said it looked good. I swapped SX28 chips and ran 11A & 11B again and still the same results. I have attached the .SRC files.
Great thanks for your continued help.
Note that both files define pin RB.7 as an output "test pin", though right now only #12 uses it.
Run these with no resonator, clocked by the key. Both show the same startup sequence for the LEDs as earlier versions.
#12: use RUN -- this program just outputs the signal detect pin onto the test pin. If you can, hook up a channel on your 'scope to the TestPin and a channel right to the input pin (RB.3). Use the fob and on your scope both channels should be essentially identical (technically, the output pin will lag by a 1/4 microsecond or so, but you won't see that difference at your 10ms scale). If this is the case, then we know the input pin is being "read" properly. If not, then we have a problem.
#13: use DEBUG -- if the results from #12 are OK, then this program just does a continous pulsin capture, without parsing it. The pulseDur is set up as a watch variable so you can halt the program. If that works OK, then #13, run in "DEBUG" will let you see the captured value of pulseDur. If you see all "grayed out" buttons in your debugger, then you have a bad or dirty connection to the key. You can optionally comment out the BREAK in the test area if you want the program to halt when/if a pulse is captured. Otherwise, you will want to hit STOP in the debugger occasionally to be able to read the watched variable value. If this works, then report some of the values you get for the pulsedur, so we can see if they are remotely in the zone. If you get no pulse durations (0 value in the watchlist), then we'll try capturing high pulses.
Does that make sense? If not, hit me up w/questions.
#12 - Ok, I ran #12 using RUN (no resonator, clocked by the key). I hooked up a channel to RB.7 & RB.3. I did get a signal from RB.7 but not RB.3. I also hooked up a channel to RB.7 and RA.3 and got two separate signals.
#13 - I could not get the debugger to work. I did DEBUG the program and still have grayed out buttons. I tried swapping out SX-Keys, changing wiring, cleaning leads, but still nothing. I also commented out the BREAk, and nothing transpired. I have attached a "printscreen" of the debugger, and the .SRC files for #12 & #13.
If I missed something, or there is something else I can do on this, please let me know,
Thank you.
Can you post a pic of your current breadboard setup?
My instincts are still that there is a clocking problem -- perhaps bad connection from the key, or the breadboard setup won't support the resonator. That is the simplest explanation for why the program essentially works, but doesn't correctly capture the pulse durations. Would also explain debugging problems. But the margin of error is high enough that even with a clock out of spec, I would still think some messages would get captured.
Thank you for your input on troubleshooting the breadboard and SX-Key connector. I think I'm going to put the components on another breadboard and clean the SX-Key again best I can.
For #14, I did RUN the program and got some responses which was great to see. The typical results I get (when I press any button such as lock, unlock, etc.) are it lights up all four LEDs, and will either just do that once, or will light up all four LEDs again and then light up two LEDs, and then they timeout. Also, when I press the Panic button (value of "10111011") there is a constant case where all LED's light up, then immediately after, it just lights up the correct LED (blue) for about 3 seconds. I have done it 10 times and I get the same results.
I have attached the .SRC file for #14.
Also, I do have two questions I would like to ask of you off the forum. Do you have a preferred e-mail address I can contact you at? Would the e-mail address that is near the top of the code you have supplied be ok to reach you at?
Many thanks.
This is probably showing the upper and lower nibbles. The fact that is might be the "correct" LED on one of the nibbles is coincidental.
The case where you had 4 leds may have been a byte of %00001111 or %11110000.
If one of your special messages is not parsed and captured, any other message should make the following happen:
- all LEDs blink once for a second
- then 4 bits of the message are displayed (all leds dark = %0000; all leds lit = %1111, etc)
- then all LEDs blink twice for a second
- then the other 4 bits of the message are displayed
Sounds like progress, though, as you would only get LEDs lit if you correctly get 8 bits plus a start bit. I'll see if I can post some variations to try out before I take off in an hour or so for the afternoon.
I PMed you about contact info.