New Bipolar Boost TX and Front End

[KingJL]

... I've been away with work and so, at night, being bored, I started designing an enclosure to be 3D printed.
No doubt it will change but piecing it together in a few different configurations is a start.
I have allowed for the boards, lithium batteries, display, encoder, on-off switch, 3.5mm headphone jack, coil socket, space for 1 or 2 push buttons or connector to handle mount pinpoint button if required.
It's only at concept stage but I thought I would make a start with measurements and making the library step model for PCBs and other parts etc...

Great... one item to consider if using the OLEDrgb display... position it and shield it to prevent it from "washing out" in bright sunlight. And allowing for a pushbutton for pinpointing is great as I was intending on using one for that purpose. On my Vallon, I use a Bluetooth 5.0 transmitter that is plugged into a 3.5 mm headphone jack and use sport "over the ear" bone conductor headphones. Those headphones are great, especially in hot weather. The transmitter is about 2"x 2.5" x .325" and contains it's own rechargeable battery that lasts about 7 hr.

[KingJL]

Logic Analyzer Waveforms

A few posts back, I said I would hook the PMOD-A7 up to the logic analyzer and post a screenshot of the output. Well, today I finally got around to it.


DIO 0 is TX_A_B switch, CMOD-A7 pin 35; DIO 1 is Boost-A_s, CMOD-A7 pin 41; DIO 2 is Boost-A_e, CMOD-A7 pin 44; DIO 3 is TXA, CMOD-A7 pin 42; DIO 4 is Boost-B_s, CMOD-A7 pin 43; DIO 5 is Boost-B_e, CMOD-A7 pin 46; DIO 6 is TXB, CMOD-A7 pin 39.

All previous timing waveforms posted were from the FPGA programming IDE simulator... these are the real thing... the actual output from the CMOD-A7 FPGA board. All timings were spot on as measured by the logic analyzer: PRT 500 usec, PW 50 usec, MPP-PW 250 usec, boost A/B s&e signals were 1.5 usec. All this while the embedded processor is merrily dealing with OLED displays, user inputs, etc.

[Mdtoday]

Excellent work KingJL, thanks for sharing, its all coming together nicely.
It's a bit early for a housing I know but I've been away with work and so, at night, being bored, I started designing an enclosure to be 3D printed.
No doubt it will change but piecing it together in a few different configurations is a start.
I have allowed for the boards, lithium batteries, display, encoder, on-off switch, 3.5mm headphone jack, coil socket, space for 1 or 2 push buttons or connector to handle mount pinpoint button if required.
It's only at concept stage but I thought I would make a start with measurements and making the library step model for PCBs and other parts etc.



cheers

Mdtoday

[KingJL]

RGB Graphic Display Added to microblaze embedded system

Successfully integrated the Diligent OLEDrgb Pmod to the system design.
Bipolar_PI(4).pdf

So far just coded a C test module to exercise the display and to verify SPI communication from the embedded processor to the actual display peripheral.


For the test, I integrated the Pmod module to the existing Pmod connector (JA on the CMOD-A7). In the future I will change the Pmod connector to one of the new ones that are on the interface board for the Bipolar PI project.

I will post a link to the updated project archive sometime in the next few days after I re-arrange the location of the library folder for the custom IP's (OLEDrgb being one of them). Currently this IP library is out side of the "Bipolar_PI" project and would cause errors for anyone just dropping and using the project archive. I want to integrate the custom IP library within the directory structure of the project.

[Mdtoday]

Hi JL,

Very nice work, thanks for sharing, I like where this project is heading, I will download your latest code and have play.
I am away with work until the end of this week and will finish off loading the 2 sets of boards I started a couple of weeks ago.
Will order the PMOD OLED etc to keep everything the same as you have for the time being.
Again, thanks for sharing.

Cheers

Mdtoday

[KingJL]

This week involved developing the code to utilize the last 4096 bytes of the flash memory to store the detector's operating parameters between operating sessions. The parameters record is only 32 bytes, but since (1) the flash must be erased (all bits filled with 1's) before a write; (2) the fact that the smallest granularity for an "erase" operation is a complete sub-sector (4096 bytes); (3) flash memory life is rated in the number of write cycles (don't worry, it is a very high number) per bit ; and (4) the "erase" command takes a relatively long time to execute, I decided to utilize the complete 4096 bytes. The implementation is much like a journal file system, where a record is not really changed but is marked as invalid with a pointer to the updated record entry. This allows 128 record updates before an erase is required and spreads the write operations across all bits of the 4096 byte sub-sector.

After implementing a method to store the PI operating parameters, C code was developed to utilize the stored parameters to calculate and provide the TXRX VHDL peripheral with the detector's operational parameters (i.e. clock counts for PRT, boost timing, PW, damp timing, samples 1 & 2, and the CIC filter's decimation rate). All calculations had been previously been accomplished within the VHDL definition of the peripheral. All VHDL computational code was taken out of the hardware peripheral and moved over to the software side within the embedded microprocessor code. Now the peripheral makes no decisions... just provide timing signals to the TX and pre-processes/filters RX signals in accordance with the parameters provided by embedded processor. All post processing of the pre-filtered RX will be accomplished by the embedded microprocessor code.

In the coming days, it is time to implement/add audio output, video output, and user input hardware modules to the design. The audio output module is essentially already designed... just needs to be integrated into the design. For video output, I plan to use Digilent's OLEDrgb PMOD (because I already have one). Digilent has already designed the C-code driver for this display... it just needs to be integrated into the design. For user input, I plan to use Digilent's rotary encoder PMOD (again, mainly because I already have one). The rotary encoder's shaft/knob is also a push button switch. The user will turn the encoder which will navigate through a set of menus and push the shaft to select the menu item/value.

The envisioned RX signal processing is as follows: (1) the outputs of the ADC for each sample (S1, S2, and S3 (S3 is taken 5 usec before the end of the PRT)) is integrated and filtered to 200 Hz. (2) during the Ground balance sequence, S1, S2, and S3 are measured with no target and no ground signal and stored. Next S1, S2, and S3 are measured with ground present and the no target signal subtracted from it thus eliminating the coil decay from the signals. This difference is also stored. Also the ratio of S1/S3, S2/S3, and S1/S2 is calculated and stored. (3) all targets will have the no target (coil decay only) subtracted from it and the ground signal difference subtracted from it, effectively resulting in only the signal level of the target. (4) Any value in S3 of the target will be scaled (according to the calculated ratios) and subtracted from S1 and S2. This set of resulting S1 and S2 signals are further filtered (in a compensation FIR filter) to a passband of 40 Hz. (5) the ratio of S1/S2 is used to determine high vs low tone. This ratio ( and the S1/S3, S2/S3 ratios) can be fine tuned by the user via the rotary encoder input.

The current development has all of the timing signals correctly being coming from the CMOD-A7 FPGA pins. In the next day or so, I plan on connecting my logic analyzer to the pins and recording their output for posting in this thread.

I have finally received all my parts from Mouser, LCS, and ebay, and will begin populating my boards this week.

The updated project archive is Vivado_Bipolar_PI(7-21-2019).zip

[Mdtoday]

This week involved multiple efforts...

You have been busy JL, that's a lot of work, thanks for sharing, I will try your latest code and make the recommended changes to directories.

cheers

Mdtoday

[KingJL]

Further... on with microblaze... a new embedded processor peripheral

This week involved multiple efforts... to package the FPGA TX_RX code into a peripheral device for use with the embedded "mocroblaze" processor, to verify upc coding access to the last page in the flash rom for TX_RX parameters, and to interact with the TX_RX peripheral with C code. The system block design with the TX_RX peripheral:
Bipolar_PI(2).pdf

During this effort to create and integrate the TX_RX peripheral, I encountered errors caused by pathnames too long for Windows 10, which required me to relocate my project directory closer to the root of the C: drive. In my case it is c:\Vivado_Projects. Also there can be no spaces in any of the directory names for the project or the build will fail. As of this moment the main.c only contains code to prove out the access to the flash rom and to verify access to the control registers for the TX_RX peripheral. This next week will involve coding the process to initialize the rom storage and the TX_RX control registers with the initial operating parameters, to update the parameters stored in rom with change operating conditions, and to accept received data from the TX_RX.

The latest project source is Vivado_BiPolar_PI(7-13-2019).zip. As you may notice, the project name is changed from the previous project zip archives. The reason is that the previous project is incorporated into this new project and is included in sub-directories of this new project. I would recommend that your project directory be no more than two folders deep off of the root of the drive e.g. C:\dir_name\Bipolar_PI\. unzip the file into Bipolar_PI.

To get into the programming code for the project:
open the BiPolar_PI.xpr
(if any changes are made to the hardware design "Generate Bitstream")
File_>Export->Export Hardware (make sure "include Bitstream" box is checked in the dialog, accept all other defaults)
File->Launch SDK (accept defaults in dialog) (will launch the SDK where all software programming occurs)

within the SDK, when a program change is made and is built with no errors, you can test it in the CMOD-A7 by:
(make sure usb is connected between usb and CMOD-A7 and that a terminal emulator is active)
Xilinx->Program FPGA
Run->Run As->1 Launch on Hardware (Sytem Debugger)

[KingJL]

It's all about heat dissipation with these regs. Max Rating has very little to do with the performance but mostly good heat sinking.

I am not really worried about the normal operating current, as the circuits should be drawing < 400mA total. But at startup, the inrush current could be relatively high. Using the 217 as a current limiter, the current would be at the set limit for about 100mS until the capacitor store is charged.

[eclipse]

It's all about heat dissipation with these regs. Max Rating has very little to do with the performance but mostly good heat sinking.

[Mdtoday]

Youtai Semiconductor Co., Ltd. LM317G, 2.2A (hopefully).

Ok, thanks, I have enough of the TI version for 2 more boards but will add some of the Youtai LM317G type to my next order with LCSC.


Cheers

Mdtoday

[KingJL]

... As a matter of interest JL, which manufacturer of LM317 did you choose

Youtai Semiconductor Co., Ltd. LM317G, 2.2A (hopefully).

[Mdtoday]

Well, it was about time to start to bring the embedded processor into the picture, sooo.... Getting microblaze up and running was fairly easy. So far I have created a configuration that includes the clock generator (that generates 2 clocks: 100MHz and 50MHz), the microblaze processor with 32 KByte block ram internal memory, external memory controller with another 512KBytes, reset controller, interrupt controller, AXI Bus Interconnect, a PIO block, QuadSpi controller (to have access to the on-board flash memory), usbuart (to be used during development and debug), and the Debug Module. Everything is up and running smoothly and I can program and interact with of the peripherals.

[ATTACH=CONFIG]46816[/ATTACH]

It took countless hours to find out exactly how to access the flash storage. But in the end the answer was there all the time (although expertly hidden). I plan to use the last subsector (4 KB) of the flash to store the the PI Detector parameters that were in effect before the last shutdown. That way the user will not have to go through the initialization procedures every time the detector is turned on. The saved parameters will only take up 32 bytes. The reason to use the whole 4 KB subsector is that the memory area, that you are writing to, must be erased (an erase sets all bits to 1's) before writing. A write, or "program" command, only changes the "0" bits where appropriate... i.e. it can only change a "1" bit to a "0"... it cannot change a '"0" bit to a "1". The minimum granularity for an erase operation is 1 4 KB subsector... thus my decision to use the whole 4 KB subsector. I have a plan in mind how to efficiently use the 4 KB block an minimize the number of times that are needed to invoke the erase command as the erase command is very time consuming. For those that are interested, the CMOD-A7's flash is 32 megabits (4 MB) divided into 64 sectors of 64 KB each, which are further subdivided into 16 4KB subsectors which are further divided into 16 256byte pages. A fully defined VHDL program takes up about half (or about 32 sectors) leaving about 2 megabytes available for the software program.

I have started programming the initialization sequence. The plan is to move all of the initialization, with it's calculations of clock counts of all events, to the software side and remove them from the hardware VHDL side. Also, any decision logic will be moved to the software side, leaving the hardware TX-RX peripheral to the task of generating TX control signals and reading and filtering the RX. All post processing to determine ground balance adjustments to Samples 1 & 2, and comparisons of Samples 1 & 2 will be done in the software. After the software decisions are made and the target data appropriately adjusted, the software will "write" the result to the hardware (VHDL) audio peripheral.

In the next week, I will be bring into the Vivado block design, the TX-RX peripheral and the audio peripheral. The key to these 2 modules was the AXI bus interface solution that was discussed in my last post. After I bring in and integrate these last 2 modules, I will post the the whole updated Vivado project.

Great news, it's looking very good thanks for sharing.
On the hardware side, I have tested portions of the power supply circuits and rewound a set of pulse transformers, was hoping to do more than that over the weekend but didn't get the time.
As a matter of interest JL, which manufacturer of LM317 did you choose, I have the TI 1.5A version

Again, thanks for sharing.

Cheers

Mdtoday

[waltr]

wow, sounds incredible.
Thanks for posting progress.

[KingJL]

Hello MicroBalze

Well, it was about time to start to bring the embedded processor into the picture, sooo.... Getting microblaze up and running was fairly easy. So far I have created a configuration that includes the clock generator (that generates 2 clocks: 100MHz and 50MHz), the microblaze processor with 32 KByte block ram internal memory, external memory controller with another 512KBytes, reset controller, interrupt controller, AXI Bus Interconnect, a PIO block, QuadSpi controller (to have access to the on-board flash memory), usbuart (to be used during development and debug), and the Debug Module. Everything is up and running smoothly and I can program and interact with of the peripherals.

Bipolar_PI.pdf

It took countless hours to find out exactly how to access the flash storage. But in the end the answer was there all the time (although expertly hidden). I plan to use the last subsector (4 KB) of the flash to store the the PI Detector parameters that were in effect before the last shutdown. That way the user will not have to go through the initialization procedures every time the detector is turned on. The saved parameters will only take up 32 bytes. The reason to use the whole 4 KB subsector is that the memory area, that you are writing to, must be erased (an erase sets all bits to 1's) before writing. A write, or "program" command, only changes the "0" bits where appropriate... i.e. it can only change a "1" bit to a "0"... it cannot change a '"0" bit to a "1". The minimum granularity for an erase operation is 1 4 KB subsector... thus my decision to use the whole 4 KB subsector. I have a plan in mind how to efficiently use the 4 KB block an minimize the number of times that are needed to invoke the erase command as the erase command is very time consuming. For those that are interested, the CMOD-A7's flash is 32 megabits (4 MB) divided into 64 sectors of 64 KB each, which are further subdivided into 16 4KB subsectors which are further divided into 16 256byte pages. A fully defined VHDL program takes up about half (or about 32 sectors) leaving about 2 megabytes available for the software program.

I have started programming the initialization sequence. The plan is to move all of the initialization, with it's calculations of clock counts of all events, to the software side and remove them from the hardware VHDL side. Also, any decision logic will be moved to the software side, leaving the hardware TX-RX peripheral to the task of generating TX control signals and reading and filtering the RX. All post processing to determine ground balance adjustments to Samples 1 & 2, and comparisons of Samples 1 & 2 will be done in the software. After the software decisions are made and the target data appropriately adjusted, the software will "write" the result to the hardware (VHDL) audio peripheral.

In the next week, I will be bring into the Vivado block design, the TX-RX peripheral and the audio peripheral. The key to these 2 modules was the AXI bus interface solution that was discussed in my last post. After I bring in and integrate these last 2 modules, I will post the the whole updated Vivado project.