New Bipolar Boost TX and Front End

[Mdtoday]

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

I'll work on it and see what's out there.
The other option is that the enclosure and handle are integral, I will cad up a number of different options.
I did do a design based on the Vallon some time ago, here is the head and a photo of a detector I recently finished . I'll have to wait til I get home to access the other drawings.

I'm sure we will come up with a suitable enclosure.

cheers

Mdtoday

[Mdtoday]

I'll work on it and see what's out there.
The other option is that the enclosure and handle are integral, I will cad up a number of different options.
I did do a design based on the Vallon some time ago, here is the head [ATTACH]46928[/ATTACH] and a photo of a detector I recently finished [ATTACH]46929[/ATTACH] . I'll have to wait til I get home to access the other drawings.

I'm sure we will come up with a suitable enclosure.

This is what I did for the detector shown earlier.
The switch is a spring return centre off SPDT, I use it for GB and Pinpoint modes.

cheers

Mdtoday

[Altra]

I'll work on it and see what's out there.
The other option is that the enclosure and handle are integral, I will cad up a number of different options.
I did do a design based on the Vallon some time ago, here is the head [ATTACH]46928[/ATTACH] and a photo of a detector I recently finished [ATTACH]46929[/ATTACH] . I'll have to wait til I get home to access the other drawings.

I'm sure we will come up with a suitable enclosure.

cheers

Mdtoday

Hi Mdtoday,

Very nice looking enclosure. That's creative using a Hammond extrusion with custom printed ends.

Looking forword to JL and you testing the complete system

Thanks for posting

[Mdtoday]

Hi Mdtoday,

Very nice looking enclosure. That's creative using a Hammond extrusion with custom printed ends.

Looking forword to JL and you testing the complete system

Thanks for posting

Thanks Altra, originally I was going to mill the Hammond end plates but I wanted to add BT , battery holder and a stand and decided to 3D print rather than bolt on bits and pieces.
I spray the inside of the printed parts with nickel shielding. The stand holds the 2 lithium batteries. BTW, I deliberately print at lower resolutions and slower speeds to get strength and texture.

JL is doing a great job with this project and I am just following along and helping where I can.
I will post STL files in due course for some enclosure ideas once I run them past JL.

Cheers

Mdtoday

[Mdtoday]

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

Here is a link to IP67 rated 3.5mm phone jacks , Mouser has stock.

https://www.cui.com/product/intercon...52b-msmt-tr-67

Element14 have a 3.5mm over-molded cable right-angle connector assembly , good quality, I use these quite often.

https://au.element14.com/pro-signal/...ble%20assembly

Cheers

Mdtoday

[KingJL]

Successfully integrated the Diligent OLEDrgb Pmod to the system design...
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.

Well... that was easier said than done. But I did it! I dropped the complete digilent ip repo into the Bipolar_PI directory structure to insure anyone can drop and run this project without having to drastically modify the environment.

I also changed the microblaze environment. Local memory was increased to 64 kBytes, stack was increased to 2 kBytes, and heap was increased to 4 kBytes. This increase was merited by the fact that the OLEDrgb graphics test would cause a linker failure of stack or heap allocation. I also turned on some of the hardware features (barrel shifter, hardware multiplier, hardware divider, etc.) to minimize memory usage.

During the testing of the OLEDrgb, I found that the RGB colors specified were not displaying correctly. Green was displaying as red, red was displaying as blue, and blue was displaying as green. That problem was traced to the digilent ip code. It seems the code was developed with the microblaze processor operating in Big endian mode. But if you are using AXI4, the microblaze compiler system is configured for little endian mode. So I modified the OLEDrgb code to do a byte swap of the rgb variable. Now what you ask for is what you get.

The current code is only test code that tests the capability to store the parameters in flash rom, tests the capability to communicate with the TX_RX module and provide operating parameters, and tests the capability to display characters on the OLEDrgb Pmod. The TX_RX module is providing the timing signals that will be needed by the PCB boards.

The current project is contained in Vivado_Bipolar_PI(7-25-2019).zip.

[Mdtoday]

Well... that was easier said than done. But I did it! I dropped the complete digilent ip repo into the Bipolar_PI directory structure to insure anyone can drop and run this project without having to drastically modify the environment.

--

The current code is only test code that tests the capability to store the parameters in flash rom, tests the capability to communicate with the TX_RX module and provide operating parameters, and tests the capability to display characters on the OLEDrgb Pmod. The TX_RX module is providing the timing signals that will be needed by the PCB boards.

The current project is contained in Vivado_Bipolar_PI(7-25-2019).zip.

Nice work, thanks for sharing JL.

I will download and have a play with this over the weekend.

Cheers

Mdtoday

[KingJL]

User Input!!!

Well, this has been a painful week (and a half). A week ago, Friday July 26, I started designing the user input hardware module that would interface the rotary encoder (with the encoder button switch), a pinpoint switch input, and a ground balance request switch) with the microblaze embedded microprocessor. Due to more than a couple of interacting issues it has resulted in about 60 hrs of headaches, one after another. But, finally today, it all came together. We now have a hardware definition module that will take the inputs described above and produces six interrupts to the microprocessor so that the software will not have to poll for these device inputs. The six interrupts are: encoder clockwise increments, counter clockwise increments, encoder button (select), pinpoint start, pinpoint end, and ground balance request. Interrupts also signal the embedded upc that a new received data set is available from the TX_RX module.

I have only one more hardware definition to integrate into the design... the PCM audio module. After that is integrated, we can start the software coding process to bring it all together. So far the TX_RX, OLEDrgb display, flash memory storage and retrieval of parameters, rotary encoder with push button select inputs, switch inputs for pinpoint and ground balance are all integrated and tested. The encoder inputs (A & B) and all switch inputs are properly de-bounced (one of the more severe headaches). The current design has the rotary encoder assigned to the J4 Pmod receptacle on the FPGA/Bipolar PI interface board.

The current Vivado block design:


The current Vivado project archive is Vivado_BiPolar_PI(8-3-2019).zip .

[dbanner]

Kingjl, thank you so much for sharing your monumental work with us on forum. It has been a fascinating journey thus far. I think your work would be regarded as nothing short of Herculean. Congratulations and well done!

[Mdtoday]

Well, this has been a painful week (and a half). A week ago, Friday July 26, I started designing the user input hardware module that would interface the rotary encoder (with the encoder button switch), a pinpoint switch input, and a ground balance request switch) with the microblaze embedded microprocessor. Due to more than a couple of interacting issues it has resulted in about 60 hrs of headaches, one after another. But, finally today, it all came together. We now have a hardware definition module that will take the inputs described above and produces six interrupts to the microprocessor so that the software will not have to poll for these device inputs. .

Excellent work JL, I can appreciate the long hours you have put into this project and it will be worth it in the end for sure, thanks for sharing.
Recent work commitments reduced the time I had set aside to completely assemble my boards and finish off the draft of the enclosure designs but now that I am back home for the next few months (hopefully) I'll be able to get stuck into it.
Again, I know it's early to talk enclosure, however, after looking at the PMOD OLED display and interface, we may have to re-orientate / position 1 or 2 IF board connectors to make assembling into enclosure front panel a little easier.
For now, we could use a short ribbon or wire connector system, I need to do some more thinking on the enclosure and still waiting on delivery of the PMOD OLED and encoder modules to see how best to do this.
Perhaps another option is to redesign a new interface board with OLED and encoder mounted directly on it after all the testing and design work is completed..

Cheers

Mdtoday

[KingJL]

For now, we could use a short ribbon or wire connector system, I need to do some more thinking on the enclosure and still waiting on delivery of the PMOD OLED and encoder modules to see how best to do this.
Perhaps another option is to redesign a new interface board with OLED and encoder mounted directly on it after all the testing and design work is completed..

From some previous projects where Pmod connectors were used, I have a small assortment of Digilent Pmod cables (8" I think). I have a couple of 12 pin cables, 1 splitter cable which splits the the 12 pin to 2 6pin connectors and 1 (or 2) 6 pin Pmod cables. The Pmod OLEDrgb uses a 12 pin connector (whole Pmod) while the rotary encoder uses 1/2 of a Pmod (6 pins). My thinking was to use a cable connected 12 pin Pmod for the OLED display and the splitter cable with one section going to the rotary encoder and the other section connecting the PP and GB switch wiring and audio PCM out..I also have used the through hole 90 degree 12 pin sockets as 90 degree socket adapters for Pmod boards/cables. I think a cable/wiring connector system gives the greatest latitude with enclosure placement/design.

I had envisioned a metal or metalized plastic 2"x2"x4" (inside dimensions) rectangular circuit enclosure with openings for the power/antenna wiring, the four side/end mounted Pmods, and the one bottom(or top depending on your perspective) Pmod which could be mounted in the main housing. Also there is the small hole opening needed for the reference voltage adjustment.

I do not think there is much more to consider as for inputs or outputs as there are only 4 (after adding the audio PCM output) more output ports that will support LVCMOS33. That little tidbit I learned from this past weeks marathon in getting the user input module integrated. I tried to temporarily add 6 test ports to the design so I could hook a scope up to observe some of the internal signals... well I could add only 5. But, in the end, 5 was enough.

[KingJL]

... I have a small assortment of Digilent Pmod cables (8" I think)...

A physical check finds them to be 6"!

[Mdtoday]

From some previous projects where Pmod connectors were used, I have a small assortment of Digilent Pmod cables (8" I think). I have a couple of 12 pin cables, 1 splitter cable which splits the the 12 pin to 2 6pin connectors and 1 (or 2) 6 pin Pmod cables. The Pmod OLEDrgb uses a 12 pin connector (whole Pmod) while the rotary encoder uses 1/2 of a Pmod (6 pins). My thinking was to use a cable connected 12 pin Pmod for the OLED display and the splitter cable with one section going to the rotary encoder and the other section connecting the PP and GB switch wiring and audio PCM out..I also have used the through hole 90 degree 12 pin sockets as 90 degree socket adapters for Pmod boards/cables. I think a cable/wiring connector system gives the greatest latitude with enclosure placement/design.

I had envisioned a metal or metalized plastic 2"x2"x4" (inside dimensions) rectangular circuit enclosure with openings for the power/antenna wiring, the four side/end mounted Pmods, and the one bottom(or top depending on your perspective) Pmod which could be mounted in the main housing. Also there is the small hole opening needed for the reference voltage adjustment.

I do not think there is much more to consider as for inputs or outputs as there are only 4 (after adding the audio PCM output) more output ports that will support LVCMOS33. That little tidbit I learned from this past weeks marathon in getting the user input module integrated. I tried to temporarily add 6 test ports to the design so I could hook a scope up to observe some of the internal signals... well I could add only 5. But, in the end, 5 was enough.

Thanks for the info JL, yes sounds like cables are the way to go.
I have been working on 2 types of enclosure. The one attached KingJL_Bipolar_TX_Enclosure_V1.pdf is a draft version which can be 3D printed in 2 sections split vertically in the centre and held together with screws.
I'll do some more work on the other one now that I have your thoughts.

Cheers

Mdtoday

[KingJL]

... yes sounds like cables are the way to go.
I have been working on 2 types of enclosure. The one attached [ATTACH]47028[/ATTACH] is a draft version which can be 3D printed in 2 sections split vertically in the centre and held together with screws.

I do not think cables pose any problems. The most critical would be the OLEDrgb as that is an SPI connection with <= 5MHz clock (I haven't actually measured it, but the parameters indicate that it should be 3.125 MHz). I have driven 5 MHz across 1 meter cable with no problem. All other connections are either in the audio or sub-audio range. Nice looking enclosure! We may have a challenge with the Pmod OLEDrgb display. When yours arrives, you'll see what I mean. It is the position of the male 12 pin connector. We may have to consider de-soldering the connector and flipping it to the other side to get clearance. There is also the possibility to de-solder and swap out with a vertical male 12 pin. De-soldering components with multiple through holes without damaging the PCB can be problematic.

What are your thoughts on power source? On my re-packaged Vallon, I discarded the use of batteries and used a USB power pack mounted in a waterproof enclosure on the tail of the shaft with the power cord going through the shaft. This provided some counter weight and provided a convenient means for ground stabilization. Just a thought. These modern day USB power packs can power a detector for days (30 operational hours or more) if needed.

One other thought on the enclosure... Let's consider the option to use a switched probe. This requires space for a 3 position dpdt switch and another coil connector. Or the coil switch might be able to be accomplished with a solid state relay(s) and a small switch on the front of the enclosure with the relay control via the electronics. The later scenario would allow the probe operation even when using an IB main coil. The software could turn the IB receive path off during probe operation. I need to research for suitable solid state relay options.

[KingJL]

... Or the coil switch might be able to be accomplished with a solid state relay(s) and a small switch on the front of the enclosure with the relay control via the electronics. The later scenario would allow the probe operation even when using an IB main coil. The software could turn the IB receive path off during probe operation. I need to research for suitable solid state relay options.

Maybe something like this. It would require a small PCB and a transistor/MOSFET to isolate the drive from the FPGA ( I would hate for the HV pulse to leak through).