mroc

the cap if for decoupling, better to put one. You have it on all circuit near the
power supply.

I think you don't have problem to use 0.1mm diameter wire, with paint isolation.

Thor

deny

Thanks, i put the Cap then. sorry, other questions...

there are any problem if after isolate the Loop, make a knot with a piece of copper wire in each corner and solder it on the plate (isolate pins) to fix it to the perfboard? this mod affect to the antenna job?

In the decoder board, there are a dead zone that you mark "leave this space clear" why?

under the PSOC board it is possible to mount any components of the phase detector?

Thanks

mv4wd

It's good to have a bypass cap, but I ommitted it since I've tried to shrink the board. Anyway there's 2 x 10uF at the input. Since all the modulation is done within the PIC, I suppose a little noise cannot cause problems. When you have multiple chips it's good to have local bypass.

I don't understand well what you mean. In my prototypes the corners are 4 small pieces of insulated wire soldered to pad and then bent to lock the winding.


That's a secret upgrade I'm working on

A guy has done it but didn't get very good readings. I didn't look deeply his layout to find problems. It's nice to have a compact board, but at the moment the more I think the more components I want to add (display/buttons/leds)

Snowblind

mv4wd: would there be a problem with me just sending just the Message1 part of the packet as far as the decoder goes in MONITOR MODE. Any problem I am having are do to my code run time I think but I want to ask.


I get a packet in there rarely and even more rare they are correct with my C code I have an old analog 20mhz scope and it is hard to see the data. I want to get the Rigol DS1054Z I should be able to better see my problem.

I have an idea for connecting the decoder up to a RPI3 and letting users connect to the wifi to view their lap times on phone using a web page. A lot of the time the track does not want to run the lap stuff for practice

lagcisco

iTrader: (40)

Would there happen to be any software to read the hardware decoder signals? Would like to interface with the decoder to know when someone passes the loop

deny

I don't understand well what you mean. In my prototypes the corners are 4 small pieces of insulated wire soldered to pad and then bent to lock the winding.

The same that you do, but the wire aren't insulated and turn around the loop one time(this is insulated)

mroc

You must go to an old electronic material discarded, and find old transformer, so you got the rigth wire...

mv4wd

Monitor mode will output any packet received as long as it has a vaild preamble (0xFC0A or 0xF916).

This sounds more like erratic noise than a signal....

Climb your mountain step by step. First make sure that in monitor mode with ANY transponder you get a lot of packets. It can be a Cano, RCHourglass 'original' or RC4 Mylaps. One packet every few milliseconds mean you'll see a VERY FAST stream of numbers on the terminal. If it's not reading either, you need to double check the loop amplifier and the input amplifier.

If you have the decoder reading with other transponders but not yours, it's time to analyze deeper the signal you're producing. Correct timing for reversing polarity is crucial. If you're using the same setup as my firmware, with the the software toggling the modulation bit, you must be sure that every 4 instructions you update the bit. This for 0 as well as 1 bit, and even across bytes making the packet. Are you using C compiler? If so, you can use the emulator and check the waveform (to do this you'd better bit-bang an output instead the modulator bit just for debugging purpose). I don't know how much control you have from C, but you should at least check the generated assembly code for that part. If possible insert inline my asm code in c source for that part. It is really tight on timing. Also beware that my send sequence does erase the RAM area containing the message.


I have an ancient HP analog scope... I'd like one as well. But it's not necessary. Use the emulator as much you can.

Show us you code and keep us informed on your progress

d3m0

Hi, I'm that guy. I make a pcb design for a compact version of hourglass decoder with smd components that will fit under psoc. Can be make at home if you have minimun skills with pcb fab. It's single layer with a few bridges.

I tested only one time and results are not good as I expected so don't discard there are some mistakes
I suspect the problem is about transistors. I didn't pair hfe of transistors and don't know how this can affect result of this differential amplifier.
As original cano design uses some weird values for resistors I put in series normalizes values so can be mounted easy.

So If someone will try it here are kicad source files.

howardcano

iTrader: (37)

I've built a few loop amps, and used my multimeter in diode measurement mode to match transistors, which was accurate enough. If that's not an option you can include the trim potentiometer to zero the offset voltage.

I'm not sure if I would call standard 1% resistor values "weird", but if you don't have them available, then connecting two individual resistors in series to get the correct value is fine. I often do that myself.

Keep the analog circuits away from the digital sections to reduce noise pickup.

mroc

What I seen on your print, may be the net from C3-1 to C2-1 ( 5V ) is not connected.

I think you have to put the sod components on the side of the BNC connector and
on the side of the soc, you put a big ground plate.
Also pay attention not to have edge has we are in HF, all must be smooth as possible,
near the BNC, with the ground could make some problem.

I am not sure the the VDDIO is the same as the VDD.

Personally, I have add a 0,1uF decoupling cap to the power as near as possible from the soc.

Thor

Snowblind

Yeah I know the PIC16F323 hardware works as I ported your asm code to it and moved the port used to for transmitter loop so I can keep the debugger connected. I have it working with the ported asm code. Every now and then I bring a PIC16F18313 that know I works to make sure the decoder is not locked up.

Use the emulator as much you can.. You mean the MPLAB X pic emu? Will it show a scope view of the CWG output?

I use the the CCS C IDE for PIC so I don't know enough about it but i installed it to work on your code and to run emu to check PIC REG settings sometimes from my C code.

Even with the analog scope I see that there is a difference but I am also not sending as much out as your hex PIC files.. It is real hard to catch the packet and it not be so dim that you can see it.

I think I was closer when I used inline asm for the SENDONEBIT code but it was stepping on the W reg value. I need to read up on putting inline asm in CCS C. I only have to use it one other time when I converted some caller ID code over to CCS C. I may just need to rework the way I was doing SENDONEBYTE function to inline the code myself. I will think about it and work on this again sometime soon.

mv4wd

I think this was about not being values in the E12 serie. My local supplier (very small) didn't have the 300 ohm. Maybe for SMD this problem is even worse... Anyway I confirm my loop amplifier prototypes have been working fine without too much selection. The first build doesn't even have the trimmer... and it works. As always I think it's better to have analog away from digital and keep the power traces as clean as possible, using a star grounding when possible. Do not mix crystal ground trace with analog ground trace.

mv4wd

The emulator is not 100% correct, the oscillator is not emulated so you will not see any input from CWG. But what you want to look for is the correct bit banging every 4 instructions of the modulation bit. Replace that instruction with a bit bang to a free RA or RB pin and you can trace in with the emulator.
In the early stage of my development I used to drive high the led pin during packet transmission, so I could have a good trigger signal to use with the scope.
Also beware that the C compiler might insert some BANKSEL instructions that will make the timing go wrong.
SENDONEBIT SENDONEBYTE macros are the only clever part of my firmware... I'm very proud of them

d3m0

Thanks guys, take note about your comments and will apply in next version