New Bipolar Boost TX and Front End

[KingJL]

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

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

[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

[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.

[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.

[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)

[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]

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]

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]

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]

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]

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.

[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.

[Mdtoday]

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.

Yes, will take the OLED position into account for sure, I currently use them on one of my designs and it is recessed into the panel and with a raised rim around it.

I use the same type of BT on my detectors too, although only v4.2 but still low latency and economical and great when out in the goldfields, you can still hear surrounding noises.
Having used nice KOSS headphones in the past which block out most of the external sound, and startled resting kangaroos jumping up out of the bush, not hearing them and only spotting them at the last second yes, I prefer to hear whats going on around me, keep the heart rate down.

[Mdtoday]

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.
[ATTACH=CONFIG]46925[/ATTACH]

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.

Great work and this shows the beauty of using FPGA.

Cheers

Mdtoday

[KingJL]

... 3.5mm headphone jack, coil socket, space for 1 or 2 push buttons or connector to handle mount pinpoint button if required...

... it would be great if the 3.5mm headphone jack was waterproof. The external pushbuttons (for pinpoint, etc) could be accommodated by a 2nd 3.5mm stereo (waterproof) jack (stereo could accommodate 2 switches).