The piezo is configurable from RCHourglass manager, or via serial port commad SET BEEP [0-255] [0 or 6-30] Set beep notification in ms when passage is detected. Duration 0 = no beep notification. Divider sets beeper frequency: 0 is only pulse, otherwise frequency is 20kHz/divider, where divider must be between 6 and 30.

Perfect!
I have here a Piezo_buzzer with built in driver which can work from 5V DC without the need to select the correct frequency: BeStar BPT2412XH16LF
It doesn't write clearly in the specifications, but I just tried, it works direct from DC, no need to control the frequency.

Please advice:

I bought some PSoC kits this week. Installed the adviced Programmer from the Cypress site and tried to upload the latest .hex file.
All fine, no errors.
I attached a 5MHz crystal as well as the two 22pF's like in several diagrams is shown to 15.2 and 15.3
But when I connect the small USB connector to a 2nd USB port, the device manager doesn't show another COM-port.
I did NOT supply the PSoC by 5V at pin VDDIO, because I measured 4.8V DC at that pin already (=due to PC USB also being connected to the large USB pads).

I measured the 15.2 and 15.3 pin of the PSoC, but there is no oscillation found. Changed the crystal out for another one did not solve it.
What is going on here?? In Marco's post that shows the method, the programming takes 23 seconds, in my case just below 4.
It looks like the target is not programmed....is my setting in the Programming environment wrong somewhere?

My PSoC setup is at this moment thus as minimal as possible, only connected the 5Mhz crystal + cap's. Supply of the PSoC through the daughterboard.


Then I tried if I could program at all. so I did the project described here which indeed worked and my blue LED can blink:

Follow the schematic of the decoder. It's not 15.2 and 15.3 ... it's 15.0 and 15.1

Owh....yes...now I see....You are correct of coarse (as designer)..
I was put the wrong direction because in some early post from other builders were pictures shown were the crystal was at the 15.2 and 15.3....See here below....


And also because the writing on the PSoC PCBA itself indicates the other 2.
I try now and let you know later this evening.

Yes, now it oscillates when using 15.0 and 15.1. On to the next stage is to try UART and send the 'VERSION' command to the small USB connector...

Those pins are meant for a low frequency XTAL for real time clock. Different thing...

Yes! Also managed to take this hurdle....So I had to include the <CR><LF> in the TX command ;-) ....

@Marco (mv4wd) You can find my €30 donation to charity in you email inbox.

Decoder is now found under COM10 in my case.
-> Update: ZRound detected the decoder in CANO Mode....not using port: 10, but port: COM10....it's in the small details :-).

8 years of development (Howard -> Marco) captured in one picture. Goal of today is to cut my old decoder hardware in two, re-use the Coax-input and connect the new design to see if we can detect a transponder.

Please don't cut that piece of history Better to make a new front end or better add a jumper to the old one and put both circuits in the box, so you can even compare the two design performance. I think it's something never done before

@Marco: By using Monitor mode, I receive these packets. From years ago when I made my transponder according the old Cano design, I programmed '404040' as the ID. Can you agree I should set the 6 digits in Zround for the tansponder_number, or should there be 8? What to do??
I hoped I could read the real ID from your RC Hourglass Manager, by learning a transponder. but that didn't help me. There only RC4 transponders can be learned.

Monitor Mode spits out the packets as received, no decoding takes place. If you want to have the 'Cano' style decoding (that is no decoding) you must use the command CANO CLASSIC MODE . But in this way RC3 transponders will not be detected with the number stamped on the case. I suggest you re-encode your transponders with the RCHourglass Manager function for PIC programming. Please have a look at command reference on the project wiki

Yes, I will do as you advise. That is probably the only good solution as well. The few transponders I have are based on the PIC12F683 design, originally posted by Howard and were programmed by altering machine_code to give me the ID I showed you. I thus need a few days to order some PCBA's for the latest transponder-design using the PIC16F18313 or do quick veroboard version.
Thank you again for your quick response and have a good week.

Gerrie

These stupid component shortage globally...not only affecting my daily job, but now also the evening hobby....Just finished my SMT version with the PIC16F18313, did a quick check on availability before ordering the PCBA....Now need to change all to the DIP version PIC. Oh well, then I don't need the ISP pins anymore and can use the RC Hourglass programming socket. That saves some space on the PCBA ;-))

OK, few hours later the DIP8 versions done. The idea is to use the round shape if the PCBA is to be mounted inside a PVC ring, cut of 32mm PVC, some 8.5mm height. The outer surface of the ring can have a groove machined in, in which the windings will fit. In case a dedicated 3Dprinted housing can be made, the disc PCBA is cut into a square which remains as a 18mm x 18mm transponder PCBA. In that case the windings are in 'free-air' fixated by the 4 poles that I see others do before me.