Hardware (#1) - Watch out! (#9) - Message List

Watch out!
 unsolved

Today I programmed my new CatFlap. This new hardware has the LM324 integrated on the PCB (not as piggy bag)

With the current firmware (0.95) the boards keeps reseting! If I dissable the do_rfid_loop() it does not reset anymore....

Hope I find the problem soon, my catfalp is not working anymore :-(

  • Message #30

    Thanks for the report, i put a warning on the start page.

    Can you send me a photo of your PCB? So i can make a wiki page to help identify the hardware revision...

    Is the printed text on the PCB still

    Pet Porte 2009
    Smart Flap
    Iss E
    

    ?

    Can you test if the pcb connections have changed? I hope i can help you fast with this...

    Andi

    • Message #32

      Hi Andi

      I have a photo of the new PCB, but don't have your mail... Can I upload it somewhere?

      • Message #33

        Thanks, send it to andi at dotnet-dev.de

  • Message #31

    Hi,

    On the PCB is printed:

    Pet Porte 100-1023 rev X6

    If I dissable detect_rfid(); The board does not reset anymore..

    I hope we find the problem soon, I don't like strange cats in my house :-)

    • Message #34

      Hmm, since there's still a LM324, i guess they just changed some connection to the MCU. Can you check the connections with a circuit indicator or something, or send me a very detailed photo of both sides of the pcb, so i can see where the circuit path go?

      • Message #39

        On my PCB is has a different version tag: Pet Porte 2008 Smart Flap Iss C

        I will ask Potporte if I can buy this PCB version to experiment.

        • Message #40

          I was reading the code of peripherals.h and I noticed you use a xtal frequency of 19,66 MHZ.

          To make the situation of different PCB versions even more challenging, my board seems to have a diffenernt xtal frequency written on the component. It reads 19,860 MHz. That would mean that each PCB revision needs its own firmware.

          • Message #42

            I just received a new PCB which I ordered. It is Iss E, 2009. The chrystal is AEL 19,6608 06/10. I'll try the firmware with this new PCB.

            • Message #44

              I think we need to make the timing constants a function of the crystal frequency, i added ticket #10 for this issue.

              • Message #46

                I just received my new scope :-)

                Also Petporte sent me a new pcb.

                Now I have 3 different pcb revisions:
                Iss C 2008: 19,86 MHz written on xtal and verified with scope (19,8606).
                Iss D 2009: 19,86 MHz written on xtal and verified with scope (19,8606).
                Iss E 2009: 19,66 MHz written on xtal and verified with scope (19,6633).

                Also I noticed that only pcb Iss C and D work with my petporte coil. Iss E, which has a different frequency, doesn't work with it. No response to rfid.

                • Message #47

                  Oh I forget to mention this was still with original firmware. I'm going to try Andi's firmware in pcb Iss D.

                  • Message #49

                    Today I programmed firmware 0.96 (without poti) to my Iss D reveision PCB.

                    First I changed the _XTAL_FREQ in file peripherals.h to 19860000, according to the frequency of my board. Then I compiled it to a hex file.

                    When I connected the pcb and connected the power, the behaviour was a bit strange.

                    First, only the green led was on (not blinking) which means it entered an unknown state, because there were no rfids programmed yet.

                    I expected both leds to blink but they didn't.

                    It was not not possible to program an rfid. When I pressed the green button for 10 sec, the behaviour was inconsistent. First time I tried it, there were about 10 quick beeps and the green led was blinking. The second time I tried it, I heard one of the locks being opened and closed quickly for about 10 times.

                    I disconnected the power and tried again, but no luck.

                    • Message #50

                      For the flashing I followed the exact steps in:
                      http://respekt-empire.de/CatFlap/trac/wiki/Flashing

                      So both "Program Memory" and "EEPROM Data" were enabled.

                      • Message #51

                        Because my xtal frequency is only about 1% different than the frequency for which Andi's firmware is written, I tested Andi's firmware without changing anything. I tested the hex file (version 0.90 downloaded from this site) but this still leads to an unknown state. The green led is on and it beeps every two seconds or so. No programming possible.

                        What timing constants should be changed when using a pcb with 19.86 MHz? I can only see the _XTAL_FREQ constant in the code.

                        • Message #52

                          I got it working now with Andi's firmware! After looking at pcb Iss D and E, I noticed only differences on the Rx board. So I used Iss D, with the Rx board from Iss E. I compiled the firmware for the frequency used on Iss D (19.86 MHz). And that combination works. I could program an rfid chip and the flap opened.

                          The reason is probably because Iss D uses the right xtal frequency for the flap coil that I have, and Iss E has the Rx board with the comparator for which Andi's firmware is written.

                          • Message #53

                            At the domotica forum, I uploaded some photo's of both Iss D and E so you can see the difference.
                            http://www.domoticaforum.eu/viewtopic.php?f=7&t=4828&start=75

                            • Message #54

                              One of the differences you can see on the photo is that it looks as if pin 5 and 6 are switched on the LM324...

                              • Message #55

                                Oops, I guess I meant pin 12 and 13. I counted from the wrong side. Isn't there a way to edit my previous posts to corrects mistakes?

                                • Message #56

                                  It's still unstable. I got it working 1 time, but after I disconnected and reconnected the power, it's not working anymore.

                                  I connected the serial port to my PC so I can read the output. What happens is that the red and green buttons are pressed randomly (EVT - green/red button pressed). And the strange thing is that it seems to be triggered when I get my hand close to the pcb without touching it... Might be an EMC problem? Or a timing problem due to the different frequency my pcb uses. Anyway, I'm sure the buttons are not pressed.

                                  To be continued.

                                  Andi, if you can tell me what timing parameters should be changed with other frequencies, it would help me a lot.

                    • Message #57

                      Hi Darwusch,

                      thanks for your research about the differences in the revisions.

                      Try to compile the latest source code 0.97 from the svn, the timer0 bugfix might help with this incosistent behaviour, like restarts and so, since it also involves the watchdog-timer.

                      The _XTAL_FREQ is mosty used for calculating the baudrate of the serial interface. But i think also the RFID-Timing constants (RFID_TMR1_*) in rfid.h might be concerned. On the other hand, you say it's only 1% difference, so maybe it has no effect after all. Here are some of my calculations for the timing parameters:


                      Frequency:
                      19660000 Hz

                      Timer Base = FOSC/4:
                      19660000 Hz / 4 = 4915000 Hz

                      Prescaler 8:
                      4915000 Hz / 8 = 614375 Hz

                      Time of one Timer1 tick:
                      1 / 614375 Hz = ~1,62767 µs


                      One full RFID-period is about 240µs:

                      RFID_TMR1_FULL_L is 240/Timer1-time:
                      240 µs / 1,62767 µs = 147,45 -> 148

                      RFID_TMR1_HALF_L is:
                      148 / 2 = 74

                      RFID_TMR1_PRE_LH is:
                      74 / 2 = 37


                      Now the calculations with 19,86 MHz:

                      Time of one Timer1 tick: 1,61128 µs

                      RFID_TMR1_FULL_L is 240/Timer1-time:
                      240 µs / 1,62767 µs = 148,9 -> 149

                      RFID_TMR1_HALF_L is:
                      149 / 2 = 75

                      RFID_TMR1_PRE_LH is:
                      75 / 2 = 38


                      So, maybe it has a minimal effect, can you try the new timing constants?

                      Also: I couldn't see wich pins are switched on the RX-pcb in Revision D, could you mark it on a picture for me please? ;) Thanks.

                      Andi

                      • Message #59

                        Hi Andi,

                        Thank you for the timing constants, I'll try them. On Iss E it seems that the resistance R30 is connected between pins 13 and 14. But on Iss D it looks like it's connected betweend 12 and 14. See attached picture of Iss D that I uploaded below.

                        Darwusch

                        • Message #60

                          Hi Andi, the svn still mentions version 0.96. Is that correct?

                          • Message #61

                            Andi,

                            I tried it on Iss D with timing constants for 19.86 MHz. The result is the same. Output on the rs232 pin is "== BAD CRC ==" every time I scan I chip. This happend both with the RX board of Iss D and E attached to pcb Iss D.

                            Also when I try with pcb Iss E, I get this "== BAD CRC ==" message. Iss E wasn't working with original firmware so I turned the screw for adjusting the coil lenght but also this didn't make any difference. I turned it the whole range in intervals of about 30 degrees.

                            Peptorte told me that the coils are all the same for all revisions of the pcb's. Only the screw can adjust for small differences in lenght of the wire of the coil. On Iss D I didn't change the screw possition because it was working with original firmware.

                            • Message #62

                              One full RFID-period is about 240µs:

                              Andi,

                              Why is is 240µs? It works on 134,2 kHz, is it calculated with this value?

                              • Message #63

                                Hi Darwusch,

                                the Version is still 0.96, just make sure the changes from changeset [27] are included.

                                The RFID activation field frequency is not exactly 134,2 kHz, its generated by timer2 and therefore dependent on the crystal freqnecy. Its calulated like this:

                                PWM Period = ((PR2) + 1) * 4 * TOSC * (TMR2 Prescale Value)

                                In our case for 19.66 MHz:
                                PWM Period = (36 + 1) * 4 * (1/19660000 Hz) * 1
                                PWM Period = 7,528 µS => 132,837 kHz

                                For 19.86 MHz:
                                PWM Period = (36 + 1) * 4 * (1/19860000 Hz) * 1
                                PWM Period = 7,452 µS => 134,189 kHz

                                By definition in ISO 11785 a bit-period is 32-times the activation field period. In our case:

                                19.66 MHz: 7,528 µS * 32 = 240,896 µS
                                19.86 MHz: 7,452 µS * 32 = 238,464 µS

                                I hope this helps you, Andi

                                • Message #64

                                  Hi Andi,

                                  But wouldn't that lead to the same timing constants, both for 19.66 as 19,86 MHz? Because if we use 238 µs for the calculations with 19,86 MHz:

                                  Time of one Timer1 tick: 1,61128 µs RFID_TMR1_FULL_L is 240/Timer1-time:

                                  238 µs / 1,61128 µs = 147,7 -> 148

                                  RFID_TMR1_HALF_L is:

                                  148 / 2 = 74

                                  RFID_TMR1_PRE_LH is:

                                  74 / 2 = 37

                                  • Message #65

                                    Hi Darwusch,

                                    hmm, i thought of the 240 µs as a constant, that was wrong, thank you for the hint.
                                    Also: Here's the mathematical proof that you're right:

                                    Error: Macro Image(discussion:message/64:tfull_proof.jpg) failed
                                    'NoneType' object has no attribute 'id'

                                    With PR2=36 we get 148 for RFID_TMR1_FULL_L, independent from the crystal frequency.

                        • Message #66

                          Ok, i see... i wonder what that changes...

                          Error: Macro Image(discussion:message/57:Rx board Iss D diff.jpg) failed
                          'NoneType' object has no attribute 'id'

                          • Message #67

                            Hi Andi,

                            Thank you for the clarification.

                            It looks as if some inputs are floating or sensitive to em-fields. Because as soon as I power up the pcb, it's beeping, specially if I come close to the board with my hands. On the serial output (in debugging mode) I read with every beep "EVT - Green/Red? button pressed!"

                            When I hold a chip to the reader, it's always the message BAD CRC.

                            And when I really press a button, nothing happens. Also no serial output message. But when I slightly touch a button on its side (where the two small metal contacts are), it does show up on the serial output as Green/Red? button pressed.

                            This is both with Iss D and E, very strange. It still looks as some floating input to me which is sensitive for noise or something.

                            • Message #68

                              Hi Andi, I see your binaries are different from mine, must be a library thing I guess. To test I'll try with your binaries for now.

                              On Iss D, I use the 19,86 MHz debug version, and on Iss E the 19,66 MHz debug version.

                              The good thing is that there is no sensitivity to noise anymore. The pcb responds to the buttons correctly, on both pcb versions.

                              Only I get BAD CRC every time I hold a chip to the coil.

                              The output is an inconsistent binary value, like:

                              Data received:
                              == BAD CRC ==
                              EVT - Detected RFID (196 bits)
                              00000000001
                                100111010
                                111110101
                                011111000
                                000110010
                                100000010
                                101001001
                                111111101
                                111111001
                                000000001
                                111111101
                                111111101
                                111111111
                                011011101
                                000111111
                                110100011
                                110001000
                                101000000
                                110101101
                                10000
                              Data received:
                              == BAD CRC ==
                              EVT - Detected RFID (196 bits)
                              00000000001
                                000111010
                                001001000
                                110111001
                                000010001
                                010000001
                                101011011
                                000000001
                                000000011
                                000000010
                                000000001
                                000000001
                                111111111
                                011011101
                                000001100
                                001011100
                                101110111
                                010111111
                                011010010
                                01111
                              
                              • Message #69

                                Hi Andi,

                                FDX-B should consist of 128 bits, but I receive 196 bits. Could it be the received wave form isn't interpreted right in my case? I would like to connect my scope to see the actual received wave and see if the received wave itself is consistent after several attempts of holding a chip under the coil.

                                Is there a pin on the pcb to try this? Coming from the comparator probably?

                                • Message #70

                                  Now I connected pin 5 from jp3 to my scope to read the wave form. I'm still figuring out how to record a certain time to capture the whole thing.
                                  My scope is a hantek 5062b. This should work.

                                  Are the extra bits (196-128) coming from the chip to sync?

                                  • Message #71

                                    I read that the protocol of FDX-B is as follows, please correct me if I'm wrong.

                                    Biphase encoding, so that there is a transition at the beginning of each bit boundary.

                                    A logic 0 state has a transition at the beginning and in the middle of the bit period.

                                    A logic 1 state has a transition at the beginning only.

                                    http://respekt-empire.de/CatFlap/trac/raw-attachment/discussion/message/70/biphase_encoding.jpg

                                    Now when I measure with my scope on pin 5 of jp3, with debugging enabled, I notice that this does not correspond with the protocol. Because after some bit periods, there are no transitions at the start of a new bit. See example, at the end the following bit has no transition at the beginning.

                                    http://respekt-empire.de/CatFlap/trac/raw-attachment/discussion/topic/9/bit-period.jpg

                                    • Message #73

                                      Hi Andi,

                                      I now connected the DEBUG_YELLOW too, so I can see when the signal rfid_sync_state = SYNC_IN_SYNC.

                                      See attached picture for an example when I hold an rfid tag below the coil.

                                      Again you can see that sometimes there are no transitions after a bit period. In the first bit period without a transition, there still is a SYNC_IN_SYNC high after a half bit period, so the software is interpreting this as a valid bit. I believe this is wrong, right?

                                      http://respekt-empire.de/CatFlap/trac/raw-attachment/discussion/message/71/bit%20periods%20with%20debug_yellow.jpg

                                      • Message #74

                                        Hi Darwusch,

                                        FDX-B should consist of 128 bits, but I receive 196 bits. Could it be the received wave form isn't interpreted right in my case? I would like to connect my scope to see the actual received wave and see if the received wave itself is consistent after several attempts of holding a chip under the coil.


                                        You're right, a FDX-B diagram is 128 bits, but the "receive-buffer" in the CatFlap-Firmware has 196 bit, to be able to record a few bits more for debugging purposes. Also in debugging mode, the "detect_rfid" routine does not stop if a protocol error occurs.

                                        Is there a pin on the pcb to try this? Coming from the comparator probably?


                                        Yes, to see the waveform directly just connect to the PINs 1 and 5 of the receiver daughter board.

                                        Are the extra bits (196-128) coming from the chip to sync?


                                        No the first 11 bits are sync bits, and included in the 128 bits.

                                        Biphase encoding, so that there is a transition at the beginning of each bit boundary.


                                        Almost. It's called modified differential Biphase (mDBP) coding.

                                        So, the first part is as you described:
                                        A change in the middle of a bit period means 0, and no change in the bit period means 1. Now the tricky part: the level changes from low to high may be advanced up to 8 activation-field periods (134kHz).

                                        Again you can see that sometimes there are no transitions after a bit period. In the first bit period without a transition, there still is a SYNC_IN_SYNC high after a half bit period, so the software is interpreting this as a valid bit. I believe this is wrong, right?


                                        Might be the advancement of the low -> high transition up to 8 activiation field periods.

                                        It's quite difficult to parse, im currently looking for a more reliable method to parse the FDX-B protocol.

                                        If you have a easy, processing-time saving solution or some ideas...

                                        Yours Andi

                                        • Message #75

                                          Now the tricky part: the level changes from low to high may be advanced up to 8 activation-field periods (134kHz).


                                          Might be the advancement of the low -> high transition up to 8 activiation field periods.


                                          Hi Andi, The advancement isn't completely clear to me yet. Do you mean that the low->high transition is somtimes postponed, exceeding a bit period? Can you give an example of a mDBP wave with the 1's and 0's written on it?

                                          On the internet I found some code from this site: http://www.elektroda.pl/rtvforum/topic988161.html#8266681

                                          This is the code attached to it: http://respekt-empire.de/CatFlap/trac/raw-attachment/discussion/topic/9/AR_src.zip

                                          Maybe there is some good idea in there? It uses a slightly different way of coding the decoding part.

                                          • Message #76

                                            Hi Darwusch,

                                            Can you give an example of a mDBP wave with the 1's and 0's written on it?


                                            Here you go:


                                            On the internet I found some code from this site: http://www.elektroda.pl/rtvforum/topic988161.html#8266681

                                            Maybe there is some good idea in there? It uses a slightly different way of coding the decoding part.


                                            Thanks, i will look at it.

                                            Andi

                                        • Message #77

                                          Now the tricky part: the level changes from low to high may be advanced up to 8 activation-field periods (134kHz).

                                          I see, thanks. The example helped a lot. In a datasheet about FDX-B I read "The FDX-B allows an advance of up to 8 clocks in the ON to OFF transition."
                                          Is that the same? Or does that mean high to low transition in stead of low to high?
                                          I guess "On" can mean either "high" or that the modulation is on (meaning "low").

                                          Thanks, Darwusch

                                          • Message #78

                                            Hi Andi,

                                            With my scope I recorded a received wave and saved it as a csv file. In matlab I wrote some code to see what I can make of the wave.
                                            The code it generates, looks ok (starts with the right header and has a control bit after every 8 bits).
                                            But the crc doesn't seem to match. I used a crc-ccitt-16 generator I found on the internet to calculate the crc. There are two possible reasons: either some bit is interpreted wrong, or the way I calculate the crc is wrong.

                                            This is what I receive, I already removed the control bits:

                                            10000000000
                                            01000110
                                            11011111
                                            11000101
                                            00010001
                                            00000010
                                            10110101
                                            00000000
                                            10000000
                                            01111000	crc
                                            00111100	crc
                                            00000000
                                            00000000
                                            00000000
                                            


                                            Then I put the 64 bit part as input for the crc:
                                            1000000000000000101101010000001000010001110001011101111101000110

                                            The expected outcome is:
                                            0011110001111000 (3C78h)

                                            But that's not what the crc-ccitt-16 generator calculates. It generates a crc of A700.

                                            Can you check what you calculate with this 64 bit part?

                                            Furthermore, the algorithm I made in matlab, checks the value of a bit period on four parts, with these percentages of the bit period:

                                            0.125
                                            0.375
                                            0.625
                                            0.875
                                            


                                            Then if either (0.125 is low and 0.625 is high and 0.875 is high) or (0.125 is high and 0.375 is high and 0.625 is low) the bit is a zero, else it is a one.

                                            • Message #79

                                              By the way, I reversed the bit order in my post above here. The control bits I removed, were at the left of each row. So it's MSB------LSB. (But you probably saw this because the header is also reversed.)

                                            • Message #80

                                              I made a crc generator with excel and also one with matlab. When I looked at the wave, I discovered six bits which were maybe incorrect. It seemed that the seventh bit in the second row was incorrectly read. I changed it:

                                              10000000000
                                              01000100
                                              11011111
                                              11000101
                                              00010001
                                              00000010
                                              10110101
                                              00000000
                                              10000000
                                              01111000	crc
                                              00111100	crc
                                              00000000
                                              00000000
                                              00000000
                                              

                                              And now the crc matches.

                                              Then I changed the algorithm a little, to read the bit periods at these percentages:

                                              0.150
                                              0.375
                                              0.625
                                              0.875
                                              

                                              And then the whole tag was read correctly. But I guess that when I make several read outs with the flap, some will have errors. We should think of a matched filter or something, to interpret each bit period.

                            • Message #81

                              Hi Andi, It looks as if some inputs are floating or sensitive to em-fields.

                              Hi Andi,

                              It seems to me that the bug I was telling about is caused by a small bug in the svn source. In file peripherals.c, the following is commented out:

                              \\ RBPU   = 0;
                              

                              When I remove the slashes and compile, all is fine, even the hex file is the same as yours.

        • Message #89

          On my PCB is has a different version tag: Pet Porte 2008 Smart Flap Iss C

          I will ask Potporte if I can buy this PCB version to experiment.

          I have just purchased a Pet Porte with Pet Porte 2009 Smart Flap ISS E on the PCB in Australia. However my cat is from the States and has a home again chip which I think is 125hz rather than 134.2 which is more the norm in Australia. Is it possible to switch the frequencies easily? I was hoping there might be a capacitor installed on the board that can be switched on to switch frequencies. It would be a shame to rechip her as the vets in Australia seem to be able to read her chip just fine.

          Thanks

          M

          • Message #94

            I have Pet Porte Smart Flap 100-1023 rev 000. For me it's even not clearly, if this revision is supported by the custom firmware. I saw that the code was last edited in 2014 and this website updated with a demo video in August 2015.

    • Message #82

      Hi Andi

      First of all, amazing work! I'm very impressed.

      Reading this thread though I'm not clear if anyone discovered the differences with the 100-1023 rev x6 board (where the op amp is not on a separate daughter card)?

      Is it just a case of changi the freucny specified in the header , before compiling?

      My crystal has A196C2C written on it - but that doesn't quite seem to match any other reports I've read.

      I read here that other's start with A196, but the remaining three letters are different.

      http://www.domoticaforum.eu/viewtopic.php?f=7&t=4828&hilit=Pet+Porte&start=75#p55212

      Any help gratefully received.

      Marcos

      • Message #87

        Can you please tell me the status of this project. I own the following smartflap with a rev E circuit board

        http://files.raqxs.nl/domotica/petporte/

        • Message #88

          I'm also not sure what the current status of the new board support is -- I do have a X6 cat flap which I've not yet installed. As there is no way back to the original firmware, I'm feeling a bit uneasy about flashing the current tree...

Attachments (3)

Download all attachments as: .zip