New Bipolar Boost TX and Front End

[KingJL]

Thinking on this more, with a little more modification to your original Probe switch layout JL, we can use 1 version to fit both areas outlined in last post.

[ATTACH]47249[/ATTACH]

May change standard header with JST latching type if they fit height-wise, existing header will still fit if preferred.

That all sounds great. I especially like the idea of using the space in the coil connector bay... it leaves options in case we need some more space along the way.
On the FPGA front, after numerous interruptions, I think I have a handle on my loss of RX interrupts. With the help of the Integrated Logic Analyzer (ILA), I have found out what it is not (which usually is almost as good as finding what it is). The ILA is a great debugging tool, as it lets you see the actual signals on individual nets... not simulations. I was concerned that it was a configuration issue with the XADC, but the XADC signals looked good. It turns out that it is in the CIC filter processing. Either one (CIC or XADC) shuts down the whole RX path, thus no RX interrupts. I will be tearing into that today.
I have not moved the project to Vivado 2019.1. I have it installed on my computer, but did not want to insert another variable into the project until I solved the interrupt issue and had a stable fallback position. I think that when the RX chain is whole again, I will define the audio peripheral before I go back to the software. Then that leaves only 2 hardware definitions to be fleshed out later... the final 40 Hz finishing/compensation filter and the slow acting mineralization filter.

[Mdtoday]

On the FPGA front, after numerous interruptions, I think I have a handle on my loss of RX interrupts.

That's good news on the code front, as you say you can now home in on the solution, excellent, it will be interesting to see what you find as root cause.

Most of my parts arrived from LCSC for the power module today...only I ordered 22uf 25v caps instead of 50v but I think I have some X7R in stock ..just have to find them.

The MT3608 modules I have received had 10uF loaded.

Also the test power PCBs should be here in a day or two along with some PCB coils.

[Mdtoday]

Here is the modified Probe_Switch Pcb KiCad layout JL.

Probe_switch_2.zip



J4 would not be loaded, rather tinned copper wire from 5 pin connector to J4 pads

Also the 5 pin connectors will be mounted to a panel that will be held in place with 2 diagonal placed screws. I will do this tomorrow.

If the Probe_switch board is mounted elsewhere, we have 2 x mounting holes.

[Mdtoday]

Updated PCB to extend rear ground plane and added isolated solder pads for fixing tin copper wire to pins on 5 pin coil/probe connector for stability.
Needs a sanity check and if all Ok and you are happy with it JL, I will place an order.

Probe_switch_3.zip

[KingJL]

Updated PCB to extend rear ground plane and added isolated solder pads for fixing tin copper wire to pins on 5 pin coil/probe connector for stability.
Needs a sanity check and if all Ok and you are happy with it JL, I will place an order.

[ATTACH]47278[/ATTACH]

[ATTACH]47279[/ATTACH]

Will the filled areas (especially the top side) pose a problem for the mounting screws? Otherwise, I see nothing wrong.

On the FPGA side, I have confirmed that the CIC sample filter is not functioning... no signals... as if it is not being clocked. For the life of me, I cannot find anything wrong. The sim works perfectly. Tomorrow, I will rebuild the TX_RX ip from scratch and see if it clears up.

[Mdtoday]

Probe Switch

Will the filled areas (especially the top side) pose a problem for the mounting screws? Otherwise, I see nothing wrong.

Good point, with a 3D printed case, no, however with a metal case, yes.
I have modified the board to have screw head clearance top and bottom.


Probe_switch_4.zip

Tomorrow, I will rebuild the TX_RX ip from scratch and see if it clears up..

Hopefully, this will sort the problem

[Mdtoday]

Also the 5 pin connectors will be mounted to a panel that will be held in place with 2 diagonal placed screws. I will do this tomorrow..

Here is the Coil / probe connector bay panel.



It is a slip fit with 2 retaining screws and a recess for soft O ring.

I will finish off the other side in next day or so, then put it aside and concentrate on loading and testing the power module circuit and other assemblies, then come back to to the enclosure (s) with fresh eyes and double check, then do the first of the prints, for the whole assembly..few hours in this lot...

[KingJL]

... On the FPGA side, I have confirmed that the CIC sample filter is not functioning... no signals... as if it is not being clocked. For the life of me, I cannot find anything wrong. The sim works perfectly. Tomorrow, I will rebuild the TX_RX ip from scratch and see if it clears up.

Well still no joy... I built the TX-RX from scratch and still the same result. Then I rebuilt the complete design from scratch... same result.

I then reverted to the 8-3-2019 version where I had RX-TX interrupts. I verified that I had interrupts... a lot of them... too many of them. In the code, I divided the interrupts by 100,000 and the were still occurring on the display about 5-8 times a second. That was after the upc executed the code to process the interrupt and display the text notification. I then viewed the actual interrupts with ILA... it appears that they were occurring every 60 ns. the should be occurring every 5 ms. On the plus side of this, while all these interrupts were occuring, the upc and code still responded to the userinput interrupts.

I have come to the conclusion that the TX-X ip is too complex with nested out-of-context synthesized ip (TX-RX->AIX->RX->(xilinx configurable CIC ip)) and the synthesized nets get dis-organized. I have to give some thought to this... I have two options:
(1) simplify the RX portion of the TX-RX to just gather the XADC outputs and the interrupt the to upc pull them. Create another ip that receives the samples from the upc and filters them through the CIC which then alerts the upc that a filtered product is available. This has the added benefit of greatly simplifying the TX-RX ip and reducing the communications register set.
(2) build my own CIC ip. I have a verilog single channel, single rate ip that I could modify for a multi-rate filter. Then I could use three instantiations of this for the three channels.

I am leaning to option 1 as I think it gives greater flexibility to the processing of the RX. It also reduces the impacts of change to the TX-RX ip. I have had numerous instances of Vivado not picking up changes to ip that are nested too deep.

Right now, my brain needs a rest!! This has been a real slog!

[Mdtoday]

Well still no joy... I built the TX-RX from scratch and still the same result. Then I rebuilt the complete design from scratch... same result.

I then reverted to the 8-3-2019 version where I had RX-TX interrupts. I verified that I had interrupts... a lot of them... too many of them. In the code, I divided the interrupts by 100,000 and the were still occurring on the display about 5-8 times a second. That was after the upc executed the code to process the interrupt and display the text notification. I then viewed the actual interrupts with ILA... it appears that they were occurring every 60 ns. the should be occurring every 5 ms. On the plus side of this, while all these interrupts were occuring, the upc and code still responded to the userinput interrupts.

I have come to the conclusion that the TX-X ip is too complex with nested out-of-context synthesized ip (TX-RX->AIX->RX->(xilinx configurable CIC ip)) and the synthesized nets get dis-organized. I have to give some thought to this... I have two options:
(1) simplify the RX portion of the TX-RX to just gather the XADC outputs and the interrupt the to upc pull them. Create another ip that receives the samples from the upc and filters them through the CIC which then alerts the upc that a filtered product is available. This has the added benefit of greatly simplifying the TX-RX ip and reducing the communications register set.
(2) build my own CIC ip. I have a verilog single channel, single rate ip that I could modify for a multi-rate filter. Then I could use three instantiations of this for the three channels.

I am leaning to option 1 as I think it gives greater flexibility to the processing of the RX. It also reduces the impacts of change to the TX-RX ip. I have had numerous instances of Vivado not picking up changes to ip that are nested too deep.

Right now, my brain needs a rest!! This has been a real slog!

That's a lot of work for you JL, for sure.
I think Option 1 sounds like the way to go, given the lesser impact to your TX_RX ip.
I have noticed on a couple of occasions that Vivado does some un-expected things when building, I didn't think much of it at the time as I thought it may be a resource bottleneck on my PC.
After I loaded your latest build with the new directory structure, the problems went away....problems like file missing errors and hanging, taking a very long time to compile..its been fine for the last 2 or 3 builds though.
Perhaps after a rest from it, the answer will present itself.

I have built a couple of versions of the power supply boards, one with MT6308 modules, the other with same parts as the modules discretely loaded on the board.





The good news is that all of the protection circuit works up to 2.5Amps, reverse polarity,UV,Short,Ov etc all good.

The bad news is that I missed a net from wiper to pot CCW which prevented output adjustment...added short link on pots , all good. see updated schematic--- KingJL_Power Module_rev1_20.pdf
The other main issue is one of noise and voltage regulation at load.
Both MT3608 modules and on board circuit exhibit the same problem at lower input voltages ~3-4v.
No load ripple is horrendous. I was expecting 40, 50 maybe 70 or 80 perhaps even 100 or so at load but none of the outputs were less than 230mV PP no load.
Replacing all caps with ones I know are low ESR reduced it to 180-200 but still quite bad.
On the regulation side and running from LIo batteries, the 20v output, the highest current I could get without dropping the output voltage more than 300mV was 50mA.
The 3v3 output modules had 2 standard diode in series to its input to drop the voltage low enough (2.9v) to get the boost required.
Unloaded regulation was fine, loaded with 75mA the output dropped to 2v.

The 5v output faired much much better, with 3.2v input and loaded to 800mA, the output voltage dropped to 4.95v, still not good but better.

All tests were repeated with both bench power supplies and Lion batteries as well as bypassing the protection circuit to confirm it was not the source of the problem.
Modules were also tested individually on the bench with resistive loads , same results.

Now I know I can improve the layout, tighten things up, thicken tracks etc, that will help but either I have dodgy components on 6 boards (discrete and purchased modules) or these things are highly over-rated current wise.

The 3v3 output would be best achieved I think, by using the module to step up from the 3-4.2v input to 5v where they are more stable and then using a LDO 3v3 linear regulator. LT have devices I use quite often which would do the job.

Of course, its entirely possible I have missed something obvious as I have only spent a couple of hours testing today so will have another look over the weekend.

[Mdtoday]

Actually, the obvious thing was sitting down reading the specs of the MT3608, at low input voltages like 3v efficiency is more like 80%
The board designs have to be a whole lot tighter to have any chance to get near their specs and realistically, perhaps 800mA-1 Amp are more reliable limits.

[KingJL]

That's a lot of work for you JL, for sure.
I think Option 1 sounds like the way to go, given the lesser impact to your TX_RX ip.
I have noticed on a couple of occasions that Vivado does some un-expected things when building, I didn't think much of it at the time as I thought it may be a resource bottleneck on my PC.
After I loaded your latest build with the new directory structure, the problems went away....problems like file missing errors and hanging, taking a very long time to compile..its been fine for the last 2 or 3 builds though.
Perhaps after a rest from it, the answer will present itself.

I have built a couple of versions of the power supply boards, one with MT6308 modules, the other with same parts as the modules discretely loaded on the board.

[ATTACH]47292[/ATTACH]

[ATTACH]47293[/ATTACH]

The good news is that all of the protection circuit works up to 2.5Amps, reverse polarity,UV,Short,Ov etc all good.

The bad news is that I missed a net from wiper to pot CCW which prevented output adjustment...added short link on pots , all good. see updated schematic--- [ATTACH]47294[/ATTACH]
The other main issue is one of noise and voltage regulation at load.
Both MT3608 modules and on board circuit exhibit the same problem at lower input voltages ~3-4v.
No load ripple is horrendous. I was expecting 40, 50 maybe 70 or 80 perhaps even 100 or so at load but none of the outputs were less than 230mV PP no load.
Replacing all caps with ones I know are low ESR reduced it to 180-200 but still quite bad.
On the regulation side and running from LIo batteries, the 20v output, the highest current I could get without dropping the output voltage more than 300mV was 50mA.
The 3v3 output modules had 2 standard diode in series to its input to drop the voltage low enough (2.9v) to get the boost required.
Unloaded regulation was fine, loaded with 75mA the output dropped to 2v.

The 5v output faired much much better, with 3.2v input and loaded to 800mA, the output voltage dropped to 4.95v, still not good but better.

All tests were repeated with both bench power supplies and Lion batteries as well as bypassing the protection circuit to confirm it was not the source of the problem.
Modules were also tested individually on the bench with resistive loads , same results.

Now I know I can improve the layout, tighten things up, thicken tracks etc, that will help but either I have dodgy components on 6 boards (discrete and purchased modules) or these things are highly over-rated current wise.

The 3v3 output would be best achieved I think, by using the module to step up from the 3-4.2v input to 5v where they are more stable and then using a LDO 3v3 linear regulator. LT have devices I use quite often which would do the job.

Of course, its entirely possible I have missed something obvious as I have only spent a couple of hours testing today so will have another look over the weekend.

I guess that as alternative we could use a fixed 3.3V LDO, adjustable LDO for 5V directly from your original Lion battery ( 2 in series ) arrangement and then use a boost regulator to obtain 20V. The 20V circuit draws less than 30 ma. The 20V does NOT need to be adjustable. The TX 5V draws ~250 ma worst case (MPP mode) and needs to be adjustable. The FPGA draws off of the 5V to a triple output buck regulator (LTC3569) regulator and draws a max of 1A (depending of the logic cell used) .

[Mdtoday]

I guess that as alternative we could use a fixed 3.3V LDO, adjustable LDO for 5V directly from your original Lion battery ( 2 in series ) arrangement and then use a boost regulator to obtain 20V. The 20V circuit draws less than 30 ma. The 20V does NOT need to be adjustable. The TX 5V draws ~250 ma worst case (MPP mode) and needs to be adjustable. The FPGA draws off of the 5V to a triple output buck regulator (LTC3569) regulator and draws a max of 1A (depending of the logic cell used) .

Ok, yes that sounds like a good alternative, I will draft something up along those lines then, I have a fair stock of LT devices both linear and switchers, we can use as required.
Once I have done the schematic Ill post so you can make adjustments,comment etc
I will still do some more checks on the MT3608 for the 20v @30mA too.

[KingJL]

New Baseline Design

Well still no joy... I have come to the conclusion that the TX-X ip is too complex with nested out-of-context synthesized ip (TX-RX->AIX->RX->(xilinx configurable CIC ip)) and the synthesized nets get dis-organized. I have to give some thought to this... I have two options:
(1) simplify the RX portion of the TX-RX to just gather the XADC outputs and the interrupt the to upc pull them. Create another ip that receives the samples from the upc and filters them through the CIC which then alerts the upc that a filtered product is available. This has the added benefit of greatly simplifying the TX-RX ip and reducing the communications register set... I am leaning to option 1 ...

We have a new baseline!!! After fighting the issue of the loss of RX interrupts for two weeks, I restructured/simplified the design of TX-RX and RX modules. Now the output from the XADC for each sample is inserted into the communications register set as they are available from the XADC, When sample 3 is inserted, an interrupt is sent to the upc. Interrupts ( the correct number) are being received by the embedded processor. During testing a notification is displayed every 2000 interrupts received. The notifications are occurring once a second as expected.

All testing/debug print statements are conditionally compiled with #ifdef and #ifndef statements. The #define for the different test/debug prints are contained in Bipolar_PI.h. Simply comment/un-comment the appropriate #define to turn on/off the prints. Also major functions of code are conditionally turned on/off with defines in the Bipolar_PI.h.

The next task is to create a filter hardware module so that the embedded processor can forward the RX data and be notified when filter outputs are available.

We are back on track!!!

New baseline for the project is Vivado_Bipolar_PI(8-30-2019).zip
Delete the folder "Bipolar_TX" from your previous project folder... it is replaced by "TX-RX" folder.

Changelog
Change Log.txt

[Mdtoday]

We are back on track!!!

New baseline for the project is Vivado_Bipolar_PI(8-30-2019).zip
Delete the folder "Bipolar_TX" from your previous project folder... it is replaced by "TX-RX" folder.

[ATTACH=CONFIG]47297[/ATTACH]

That's excellent news JL, well done!

I will download have a look, thanks for sharing.

[Mdtoday]

I have been busy with testing the power supplies and redesigning the power board for lower noise.

The MT2608 modules have a less than optimum layout, so I have reduced the switching current paths to minimum with an on board circuit and dropped the option for modules

Here is the latest schematic. KingJL_PWR_Rev2_00.pdf, I have used low noise LDO regulators LT1963AEQ which are me-too type available from LT, TI and 2 other manufacturers.

still some tidy up to do and then sanity check

Enlarged the pads on the battery holder footprint as I had to trim the SMD tags on the actual holder to fit Rev1.00 board. Added 4 mounting holes and removed cut-outs on board sides.

The batteries are now back in series and using 2 LDO linears for 3v3 fixed and 4.5-5v adjustable supplies. JL, I have stock I can send with the boards and will also load some boards some for you too.

Ill do some more work tomorrow and post Kicad files, then order boards after sanity checks.

The switch mode has provision for shield which helps with radiated noise. The TPS7A49 works well as the post regulator for the switcher and is optimised for High PSRR up to about 400kHz, the MT3608 is 1.2MHz and while the test board showed a huge reduction in output noise and PS ripple,it may not be so on the finished board, it should be , but we will see.