Fred, thank you so much for such an in-depth response!
Great insight into the conical shape of the field and where the most control is the most useful. Shading, or lapping, the volume antenna elements seems very desirable then.
I wasn't planning on X-Y-Z response, only Y-Z for the reason you describe: unwanted interaction with the pitch antenna.
The processor is coming along, no major bugs in simulation yet, still tweaking the opcodes.
Vanished into the ether! -- Problem in hyperspace - too much of it!
Now this is real weird! I can edit the last posting, but I cannot see it unless I edit it!
Going to try pasting it here.. If it pastes, I will delete the last (blank?) posting.
taken a quick look at the PSoC data sheet (CY8C54): the AD / DA converter resolutions are kind of low,
One can get 20 bit A/D on the more expensive parts. D/A's are low - but there is a block which can output to external serial D/A under DMA control.. The on-chip D/A's are only really useful for other functions (not audio).
the processor seems overly complex,
Its a standard ARM processor on PSoC 5, and standard 8051 core on PSoC 3
there are too few programmable logic blocks and they're very old school (PLA? - I want LUTs & FFs)
There are LUTs and FFs - The "blocks" concept is a hangover from PSoC 1 days - The fitter creates the "blocks" in the CPLD but one can create your own stuff using schematic or verilog entry, package them (if you wish) as "components" and the fitter will pack far more into the device than one is led to believe.
and switched capacitor stuff doesn't really interest me.
Its only of interest to analogue nerds like me! LOL - The S/C is extremely difficult to configure for anything except the standard pre-packaged ' components' - it was my speciality on PSoC 1, and I actually developed a simulation model for it.. I worked with Cypress and a company producing co-simulation software (simulating processor and peripheral components - bith digital and analogue) for several months, before some idiot director there stopped real development projects and went for his "Express" concept.
Their MachXO is a thing of beauty
MachXO is a thing of beauty - but its Lattice not Cypress! I used their Mach 4 parts extensively.
Their tool sets could use some work though - I particularly didn't like the license expiring every year or so.
Agreed - But, again, this is Lattice not Cypress. Cypress did other nasty sneaky things with their development software - I had a perfectly working PSoC Designer which I depended on (and was working on projects for clients) and the upgrade removed my working "Designer" and installed the unworkable "Express" toolkit.
PSoC is not everyones 'cup of tea' - The low cost PSoC 1's are, IMO, fantastic parts - cheap enough that you can splatter them all over any mixed signal board almost as if they were logic (they are cheaper than a 22V10 GAL).. The new PSoC's are on the expensive side IMO. Stupid thing is that their cheapest PSoC 3 DK costs the same price as buying the processor on this DK - and the board is packed with other expensive chips and bits (like an accelerometer!)
"...this is Lattice not Cypress" - FredM
Brain fart - I'm such an idiot sometimes!
"There are LUTs and FFs..."
I'm looking at the CY8C55 datasheet and all I see is old product term stuff (big AND gate array followed by smaller OR gate array) in the PLD block - am I missing something? FPGAs (and the MachXO) have look-up tables followed by flip flops.
It's very interesting that you worked so closely with Cypress.
And I stand by my assertion that the ARM is overly complex ;-) (particularly for this application).
First, I need to make this "disclaimer" LOL! ;-) I am only starting to get into the new PSoCs, so dont really know what I am talking about on them! - Also, my work with CPLDs has been quite elementary, so I am not placed to compare the archetecture of the PSoC UDB against other CPLD / FPGA -
"I'm looking at the CY8C55 datasheet and all I see is old product term stuff (big AND gate array followed by smaller OR gate array) in the PLD block - am I missing something? " - Dewster
No, I dont think "you" are missing anything - IMO, Cypress is missing "something"! - Once again - They seem to think that complexity frightens people, so seem to simplify things and in the process serious designers look at their products and walk away.
You are right when you say the PLD structure is the tired old AND OR product term stuff - But each UDB is much more than just PLD - Each contains 2*PLD's; Datapath components (ALU,4*Registers,2*FIFO etc) ; and other routing / chaining logic - but you can only directly access these if you go in at schematic or verilog level.
As far as I can see, IMO, Cypress has screwed up a bit in the way it is presenting its new archetecture - They are providing "Pre-assembled components" for designers to "wire" together.. These "Pre-assembled components" are great, and makes moving designs from PSoC 1 over to the new PSoC's easy - The trouble is (IMO) that the new PSoC's are a massive evolutionary step from PSOC 1, and thinking about them with the same paradigms used for PSoC 1 makes it likely that many designers will miss out -
The real power of the new PSoCs is that one does not need to use these "components" - one can insert logic and LUTs and FF's, have these connecting to I/O or to the datapath - and you can "package" your "constructions" into reusable "components" in a hierarchical manner.
As I say, I am not sure how it compares to a dedicated FPGA/CPLD like you are using, and I suspect it is greatly inferior for the kind of app you are working on - but most peeps do not intend to design a processor when they select something like a PSoC, I guess!
Ps - the PSoC 3/5 Archetecture TRM gives a bit more data on the UDB's. Page 36 in particular may be of interest - it shows the ALU stuff.. There are 24 of these on a PSoC - not sure if a processor designer could use them.....
For those interested, here is a short comparison of product term vs. LUT:
For smaller designs the PLD product term approach is OK, but it's almost trivially easy to cross over (even unintentionally) into territory where it makes more sense (cost, performance, etc.) to implement the design in a LUT based architecture. Adding other highly specialized blocks to this is nice, but again I'd rather design my own and tailor them exactly to my application. I believe the main cost drivers in PLD technology are the large EEPROM based switches.
Modern FPGAs (even at the low-cost "value" end) have DSP blocks (often attached to block RAM) that can do all sorts of stuff, and can perform a different operation on each clock (i.e. pipelined).
Even several years ago it seemed to me that industry was moving away from product term. I stopped using CPLDs the minute MachXO came along, the ability to reconfigure a product out in the field via software was too strong (this significantly reduced the "do or die" verification pressure on me as well).
Today ("s44_2012-07-15.rar" at the DT repository) I rashly gave in to simplicity. With the exception of copy, ALL single operand instructions ONLY operate on P. This makes the switching before the ALU exceedingly simple, but more importantly makes the CPU easier to handle conceptually. But it precludes a free move, so call me crazy (because I probably am).
Today ("s44_2012-07-22.rar" at the DT repository) I glued a register set, UART, two timers, and 7 segment hexidecimal display to the S44 core. It's taking ~70% of the target FPGA, still compiling comfortably with 80MHz clock (4 threads running at 20MHz each).
I included some new opcodes that use 5 bits of immediate data:
- variable size sign extension
- variable size zero extension
- power of 2 (shifted 1 in field of zeros)
- barrel shift left & right (signed & unsigned)
- add & subtract
The barrel shifter and add/subtract can also be used with two operands rather than a single operand and immediate data.
To make room for these I got rid of several conditional immediate relative jumps.
I'm getting super exhausted of coding this thing, time to instantiate it inside the FPGA with the Theremin DPLL and segue as much of the firmware into software as possible.
Still hacking away on my processor, hoping to finish it in this millennium. An almost entirely thankless task - and a procrastinator's dream come true!
SO - what are you doing?
Me (gazing at the ceiling) - working on my processor...
I exaggerate a bit, but it's almost that bad (or good, depending on how you look at it). I'm coming to the conclusion that I'm one of those people that is difficult to live with.
There's a new verilog zip file in the digital Theremin repository:
I've set the processor aside for a while, it was just getting in the way of further testing and polishing of the AFE and DPLL. After some further simulation I decided to dramatically increase the AFE tank and linearizing inductors, which dropped the operating point to around 66kHz (no one can complain about EMI/RFI there!). There's quite a bit less dynamic current flowing in the inductors (<1mA) and I'm getting better (larger and less bobbly) pitch numbers from the DPLL.
Strangely, the old "linearizing inductor built into the antenna" trick seems to be failing now, as it makes for a much less stable configuration (it also picks up more external interference from my fluorescent desk lamp, and the headphone wire influences pitch a lot more) than simply placing the inductors on the breadboard with the rest of the AFE. Not sure why this is, but I guess it simplifies the antenna construction.
I also put a second order delta sigma D/A in there, and it's working much better than I could have expected in terms of SNR and idle tones. I'm feeding it the NCO ramp through a triangle converter. Surprisingly, clipping the triangle tops and bottoms doesn't add much in the way of audible harmonics.
Next up: linearization.
Theremin design is like climbing Everest! Where every stray femto Farad and every tiny bit of environmental noise is doing its level best to send you to the loony bin.
- AFE inductor/cap resize: 1mH=>100mH, 22pF=>10pF, 4mH=>200mH @ pitch antenna.
- Drive resistor is now 2.2k (was 100, the new coils provide HV with lower I).
- Seeing increased precision due to less averaging and ~10x smaller phase dither.
- Seeing some interaction between hex display and low pitches.
- Now using button & button to adjust PLL center frequency.
- Added LPF to PLL PEI output - this is a huge improvement!
- Added 2nd order modulator attached to nco ramp.
- Added ramp2triangle.v component to give triangle and clipped output waveforms.
- Cleaned up & simplified PLL parameter calculations, some renaming also.
- Enabling PEP now doesn't seem to cause sticky points, but I'm leaving it off.
- With 200mH inside antenna:
- Lots of interaction via headphone cable.
- Fluorescent lamp interference.
- 78 kHz null freq.
- With 200mH on breadboard:
- Quite a bit more stable.
- Less interference with fluorescent lamp.
- 66 kHz null freq.
"Strangely, the old "linearizing inductor built into the antenna" trick seems to be failing now, as it makes for a much less stable configuration (it also picks up more external interference from my fluorescent desk lamp, and the headphone wire influences pitch a lot more) than simply placing the inductors on the breadboard with the rest of the AFE. Not sure why this is, but I guess it simplifies the antenna construction."- Dewster
Real interesting results - the lower frequency is more similar to conventional short-range capacitive sensors I have seen, and the mode-0 operation is also similar, but they dont have a liearizing inductance.. And these often are AFE's with following digital circuitry.
As for the antenna inductance - that is a really large inductance! - Perhaps with such a large inductance magnetic coupling to the inductor becomes significant, and the orientation of this inductance WRT the fields is whats making the difference (?) .. At least the inductors SRF and capacitance wont cause a problem, even if you used a small mains transformer as the inductor! ;-)
Be real interesting to see what range and linearity you can get.