FeelTech FY6600 60MHz 2-Ch VCO Function Arbitrary Waveform Signal Generator

[soundtec]

Just looking back on the schem ,maybe I was wrong about the outputs being grounded at zero HZ frequency output , depending on the range your using though the output attenuator might be engaged .So I wonder does the muting I hear when I switch frequency to zero happen digitally . I might be able to do some more meaningfull tests on my friends bench soon ,maybe a comparison between a modded fy6600 and an unmodded fy6800 might be a plan .

[Yansi]

Peeking in the thread, after some months... interesting guys, how far it has gone! Thank you for the schematic, that was a tough one I guess.

Seems the VCO BNC input is sampled by the ADC in the MCU on the front board?

Also, wazzup with the THS3002? It seems you can barely find a datasheet for it. (Old 1999 revision listed by only some Chinese site with a download speed of a dial up...)

[cybermaus]

you need to look for the THS3001 data sheet, the THS3002 is just the twin variant and described in the same document.

[Yansi]

Nope. Texas Instruments website does not give shit about THS3002. Only 3001 is listed and the datasheet (last revision 2009) lists only THS3001, not THS3002.

The only place THS3002 is listed is in this datasheet from 1992, where it is listed as "product review". Guessing it never took off, was not produced, or only for a short time.

http://pdf.datasheetcatalog.com/datasheets/700/322243_DS.pdf

[bdivi]

This is because THS3002 has been discontinued long time ago - last datasheet is from 1999.

Anyway we now have 3091/95 and 3491 to play with :-)

No need to investigate further what happened to 3002. I even suspect it to be a knock-off of some sort but I do not have the time to compare the performance to two real 3001 on the same board.

[cybermaus]

This is the one that usually comes up for me: http://pdf.datasheetcatalog.com/datasheets/700/322243_DS.pdf

It is from 1999, indeed, but not product review or anything. And 1999 is not so long ago guys. I remember it well. Y2K for business, new happy dawn of a new millennium, with communist/nuclear threat gone, brave new world with free information coming up and all.


Anyway, its not really important. Its 100% sure an old device, its 50% sure either a clone, or maybe cheap old stock. And its 100% sure we have better devices.

[DerKammi]

It took a while indeed, but worth the time. Still need to do the counter input though.  No prio with the nice weather here 

The VCO is indeed directly connected to the mcu. Just have a look here for the frontpanel schematics also.

Peeking in the thread, after some months... interesting guys, how far it has gone! Thank you for the schematic, that was a tough one I guess.

Seems the VCO BNC input is sampled by the ADC in the MCU on the front board?

Also, wazzup with the THS3002? It seems you can barely find a datasheet for it. (Old 1999 revision listed by only some Chinese site with a download speed of a dial up...)

[Yansi]

Well, had a brief look at the front schematic:  BOOT0 pin should NOT and NEVER float.  Maybe a connection to ground is missing in the schematic.  And the pullup on NRST is also not a recommended practice**. But anyway, thanks for the schematic also, I see how the VCO is implemented. However, they clamp it to a wrong level voltage using the BAV99. Should be clamped to 3V3 not 5V.

The whole generator thingy seems to be good to have a complete HW redesign - especially with regards to the PCB layout, which is a bit horrid in soem areas. (for exampel the DAC filters, etc..) It would certainly make it a tad better.

Y.

//EDIT: ** for STM32 micros, the pullup on NRST is not recommended.

[Miti]

Stupid question, the blue pill board doesn't drive the display...yet, it's controlled from the PC only?

[DerKammi]

Ohh sure there will be some mistakes in the schematic, no doubt I'll beep them out and correct the file when I can. The clamp diode sure make sense

I agree on the layout. The return paths are non existent in some parts of the board.

@Miti: Correct

[Mozee]

Amazing job guys!! Really this is the least one can say!
Did the FY6800 show up yet? where to buy it if so?

[soundtec]

I should be due a FY6800 once they become available ,but it doesnt look like there on sale to the general public just yet .
I also wonder about the plethora of rebranded Fy6600's doing the rounds of late ,Adoner(kebab?)and  Kuman are among them,I wonder are these knock offs or simply a rebrand made by Feeltech.

[DerKammi]

Just to make sure, I did say correct, but this will hopefully change in the future as the plan is to replace the firmware of the unit with fremen his creation. But how and when it unknown.

Stupid question, the blue pill board doesn't drive the display...yet, it's controlled from the PC only?

[Mozee]

Did anyone try these rebrands (copies?)? I saw a listing of the same unit made by Kooletron if I'm not worng spilling it 
anyways, If they offer a good warranty then that will be really good

[DaveR]

The Koolertron units are rebadged JDS6600s, not Feeltech FY6600s, and are sold with a 33% markup in the UK.  The Kuman units are probably rebadged Feeltech products (they quote the same Feeltech model numbers in the descriptions, even though they don't appear on the cases), and again they have a huge markup over the Feeltech versions.  However, I don't imagine the electronics inside the boxes will be any different from the JDS and Feeltech originals.  The Kuman units still have the two pin mains connector on the back, so they are hardly "improved" Feeltech versions.

[fremen67]

What I do know is we can easily make a sine-into-gate wave ourselves. In fact, I think it is already there, on the TTL and/or SYNC-OUT ports.
We may need to replace the standard gate with a faster one, but after that we could add an extra OpAmp amplifier. Or even feed the gate output back into present opamp by means of an extra relay (so Fremen67 can control it with a spare GPIO, and the amplitude setting works)

Good idea indeed.
We don't have a lot of spare GPIOs, in fact only one from what I recall (PA6) and the wiring could be difficult. But should it happen, we can use the bluepill for extra GPIOs. We just have to leave it connected as it is now and add an extra ribbon between the bluepill and the front panel: either with a serial link or a SPI link. We have the choice.
Should we choose the serial link, than the FP would have a spare SPI port (the bluepill too...) and we could also connect something like this : https://www.aliexpress.com/item/For-Arduino-W5500-Ethernet-Network-Modules-For-Arduino-TCP-IP-51-STM32-SPI-Interface-3-3V/32673979144.html?priceBeautifyAB=0
If you see what I mean 

[cybermaus]

Ethernet would be sweet. But I think we should take care not to get too distracted or carried away. Ideally your software should work on FP without any required hardware mods. Even my suggestion was maybe off-track a little.
But I ordered one of those ETH anyway. just in case. 

Programming by STLink seems best to me, as the header for that is already on the board, and with the ST tool, it is very simple, no commands, no linux, no nothing.

Also, sorry, my schedule is very full till middle June. lots of travel, so weekends too. Still wandering this board as a relaxation breather between other stuff, but I am really not going to be good for any proper testing.

[Yansi]

Jeez guys... Leave the Wiz*gizmos for arduino kiddies. If you that much need the ETH and want to spend the extra time and effort, do it properly using a MCU with integrated ETH/MAC. It is not magic to make a custom ETH application, just add the ETH/PHY chip and connect it up. It's not even complicated. There's enough code to get it up and going already written, no need to reinvent a TCP stack.
Leaves you debugging just one faulty firmware: Your's on the MCU, not two (MCU and the wizmo module).
In that case, I'd redesign the front panel PCB to accomodate for all the HW updates of the FP.

STLink is of course the recommended way, using the bootloader is just for the situations where you want to get mad quickly.
You could also use any of the free toolchains for STM32, no need for linux either. AC6 Workbench, Atollic,...  Will get you allso full debug support on the MCU - which I find mandatory when developing such complex applications.

Good night! 

PS: Yes, I hate those half arsed solutions. 

[nctnico]

Jeez guys... Leave the Wiz*gizmos for arduino kiddies. If you that much need the ETH and want to spend the extra time and effort, do it properly using a MCU with

Actually the W5500 chips work like a charm if the board layout is good. Messing around with a TCP stack in a microcontroller usually sucks and it won't be able to get rid of all the broadcast traffic you have on a network and you need an extra chip in the form of an ethernet PHY anyway so part wise you don't gain that much.

[fremen67]

Ethernet would be sweet. But I think we should take care not to get too distracted or carried away. Ideally your software should work on FP without any required hardware mods.

Of course. This would be for future extension.

But I ordered one of those ETH anyway. just in case. 

That's wise 

Programming by STLink seems best to me, as the header for that is already on the board, and with the ST tool, it is very simple, no commands, no linux, no nothing.

I would not use Ethernet for programming purposes. Only for remote connection.

Also, sorry, my schedule is very full till middle June. lots of travel, so weekends too. Still wandering this board as a relaxation breather between other stuff, but I am really not going to be good for any proper testing.

Same here.Though I usually not travel during weekends. I still have one kid at home. But I also really need this to change my mind.
But no worries. No customer will ask for penalties regarding production losses 

[fremen67]

Jeez guys... Leave the Wiz*gizmos for arduino kiddies. If you that much need the ETH and want to spend the extra time and effort, do it properly using a MCU with

Actually the W5500 chips work like a charm if the board layout is good. Messing around with a TCP stack in a microcontroller usually sucks and it won't be able to get rid of all the broadcast traffic you have on a network and you need an extra chip in the form of an ethernet PHY anyway so part wise you don't gain that much.

+1
@Yansi
Even changing the FP MCU for one with integrated Ethernet won't do the trick. In sweeping mode the FP MCU is able to send updates every 10µs to the FPGA. If it starts doing other things it won't be able to cope.
With the current Feeltech design, the FP MCU has to refresh the screen plus doing real time stuff... not ideal.
Regarding the current price of the FY6600, re-designing the FP would be overkill.
Adding a second MCU would allow the FP to focus on non time sensitive tasks... and we already have a bluepill in the game.. why not use it?
We already spent 2$ in a Bluepill.. we may also afford to spent 3$ more in a W5500 

[Bob Sava]

I'm curious, when using Bluepill would it be possible to use i2c programmable any-frequency generator to remove jitter?

https://www.silabs.com/documents/public/data-sheets/Si5351-B.pdf

[fremen67]

I'm curious, when using Bluepill would it be possible to use i2c programmable any-frequency generator to remove jitter?

https://www.silabs.com/documents/public/data-sheets/Si5351-B.pdf

The idea is interresting. Say we don't want any jitter between a frequency of 50Mhz (5 samples) and a frequency of 62.5 Mhz (4 samples). The idea would be to always have 4 samples in this range. That is to control continuously the sampling rate from 200Msample/s @ 50Mhz to 250Msample/s @ 62.5 Mhz. If the device is able to generate a frequency that would change precisely betwwen 40Mhz and 50Mhz that could work... provided that there is an easy way to find the correct parameters for the device in real time.

[nctnico]

I'm curious, when using Bluepill would it be possible to use i2c programmable any-frequency generator to remove jitter?

https://www.silabs.com/documents/public/data-sheets/Si5351-B.pdf

The idea is interresting. Say we don't want any jitter between a frequency of 50Mhz (5 samples) and a frequency of 62.5 Mhz (4 samples). The idea would be to always have 4 samples in this range. That is to control continuously the sampling rate from 200Msample/s @ 50Mhz to 250Msample/s @ 62.5 Mhz. If the device is able to generate a frequency that would change precisely betwwen 40Mhz and 50Mhz that could work... provided that there is an easy way to find the correct parameters for the device in real time.

You can't switch these frequency generators without a hick-up in between.

[rhb]

Would someone please point to *how* the sweep is implemented?  My question is about the algorithm.  My apologies if someone answered and I missed it, but this is a rather busy thread.  Go away for a few days and it's impossible to catch up.

How is the sample clock implemented?  is it done in the FPGA or a separate device?

For the level of work that has been expended, I think we could have an OSHW device of higher quality using a Zynq dev board for not a lot more money than the FY-6600 after the various upgrades and fixes.

I'm still waiting for my CH134A programmers to arrive.  I'm beginning to feel as if I am waiting for  packages from Godot.