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

[zov]

DerKammi, IIRC it's you who decrypted SB PCB layout and made its circuit diagram. If it don't burden you very much can you trace and depict the following pins of FPGA: MSEL0-3 and all JTAG related TCK, TMS, TDI, TDO. Are they hardwired to PWR/GND , left floating or pull-up/pull-down with resistors? It is crucial for developing/debugging FPGA config.

[DerKammi]

I'll beep them out this evening. No problem

I'm very much agreeing with Cybermaus on the voltage level switching when upping the frequency, major annoyance. This is something we can address luckily.

[SMB784]

Hey guys, I haven't been able to contribute much, but today maybe that can change.

I was successfully able to get my supplier from eBay to mail me a replacement version 3.2 chip for my working version 3.1 unit. That means that we have a currently functioning 3.1 chip available that we can test and monitor until it fails. Do yall think that this would be helpful in our attempts to fix the firmware problems in 3.1?

I am willing to send this chip anywhere in the world at my own expense if it would help in this effort, once I have received the replacement chip and have verified that it is working and of the correct version.

[DerKammi]

DerKammi, IIRC it's you who decrypted SB PCB layout and made its circuit diagram. If it don't burden you very much can you trace and depict the following pins of FPGA: MSEL0-3 and all JTAG related TCK, TMS, TDI, TDO. Are they hardwired to PWR/GND , left floating or pull-up/pull-down with resistors? It is crucial for developing/debugging FPGA config.

MSEL0 - GND
MSEL1 - 2V5
MSEL2 - GND
All hard tied.

TCK, TMS, TDI and TDO are not connected to anything.

I hope this is good news 

[DerKammi]

Also made a flash dump of both units. For a large part they are the same but there is a difference. Also compared to the file from Fremen there is a difference. Both at the same address.

Bit to tired now for a deep dive but for the ones just waking up... Knock your self out.

[fremen67]

cybermaus noticed random values when launching PC Software, see here https://www.eevblog.com/forum/testgear/feeltech-fy6600-60mhz-2-ch-vco-function-arbitrary-waveform-signal-generator/msg1444331/#msg1444331

Just tested several times, I always get the right values. Only when generator is offline results are strange, see pic.

Thank you. When there is no communication, you see the screen as it is in dev mode.  Everything is OK then.

[fremen67]

Even though I don't know enough to contribute to the software/firmware side of the FY6600, I am following this with great interest. Keep up the good work, I'm sure there are many others watching your progress.

Sure there are undoubtly many other, I am one of them. Great respect for those guys doing a lot of work!

Sure there are undoubtly many other, I am one of them. Great respect for those guys doing a lot of work!

Same here interesting  stuff !

Thank you for your support. Very much appreciated. Always funny to see what a small group can do when motivated...

[fremen67]

fremen, do you know whether there is calibration info send out to the FPGA?

No. None that I saw appart from calibration data that are sent when starting up.

Depending on the output range, the scaling formula is different (see the excel sheet I posted some time ago) but that's all.
This is the next step we will have to work on. We will have to characterize the outputs to find flat parts on each range, then choose thresholds and add calibration data for each output and channel. For that I will release a FW version where we will be able to choose and lock an output range. We will also have to find the best limits for each wave (max frequency) and also max output depending on frequency. After that I will be able to add calibration data in a new firmware. If it's only 2 points by range then this will be easy to do. I will add this in a system tab in the PC Software.

Yesterday during testing I saw the PP voltage of a sine drop when I went over 5V, thus switching to the opamp buffer. This will lover the DAC output consequently off course. But the output dropped. I did not notice this when using the FP.

At the moment I programmed the same thresholds and used the same scaling factors than the one used in the original FG. The difference in output when changing range is logical as there are not hardware calibration possibility for all the ranges.

[fremen67]

I did at some point get annoyed when dialing up the frequency past 20MHz (I think 20 was the limit), and having the Vpp click down from 10Vpp to 5Vpp
It should not change the offset or amplitude just because you are changing frequency. Instead, refuse to set the new frequency.

Yes I understand that this could be annoying at some point but it's the way it is done in several FG I have (Siglent, Hantek, even Feeltech...). This is the "Frequency priority" function and seems to be a standard way to do. When starting the FG you could also be annoyed that you first have to change your voltage to be able to select a frequency...
Anyway, it's not a big deal to add a configuration switch that inhibate this functionnality if you find it annoying. I will do it.

On the other hand, if you want to go up to 30Mhz, and it is not letting you, it would be nice if it indicated why not. Maybe by flashing the amplitude inverted red every time you try to tick past 20MHz. Same if you try and up the amplitude and it will not let you: flash inverted red the frequency or limits.

Yes this would be a nice way. I could also add it to the PC Software but it's a matter of time and priority. I will see where I can place it in my Doto list which goes on growing 
As I explain some time ago, I used the Feeltech Software as a front end because it was already there plus Feeltech made the source code available. So that was the quickest way to go with the possibility to change things, should it be necessary.
The fact is that I had to change things in this software much earlier than I had expected. Actually this PC software has been developped with Visual Basic 6.0. A 20 years old IDE, more than obsolete for a long time now. So this is clearly not the best choice for an application that is suppose to grow.
I know that all the functions I add in the firmware, even if it's in the BP now, wil be usable later on with the onboard LCD.
Not sure about what will happen with the functions that I add in the PC Software now. There are things that I also want to add like Frequency/Period switch, Amplitude&Offset/Voltage High&Voltage-low switch, mHz/Hz/kHz/Mhz choice, .... but all of this is time and this may be wasted work/energy as long as we don't know what will be the final PC front-end..

This is not exactly what you asked about of course, but related and I was reminded of it.

No problem. This is the exact right place to discuss those things 

As to locking the relays/range:

I noted that when you change frequency, the FPGA does that seamlessly. Not a single sample missed in the signal train, it even stays in phase, just at a higher frequency.
Except when it also changes range, then you loose signal for a few ms while it ticks over.  So I can see a locked relay being useful sometimes.

Yes that was exactly the point.
In the original FG firmware, you will notice that feeltech added a 4ms slot time with no signal when switching ranges. This a bit overkill so at the moment I just change range and send the new scale value at the same time...does not seem to be that bad but it's a point that may be improved in the future. Tests will tell...

[fremen67]

Hey guys, I haven't been able to contribute much, but today maybe that can change.

I was successfully able to get my supplier from eBay to mail me a replacement version 3.2 chip for my working version 3.1 unit. That means that we have a currently functioning 3.1 chip available that we can test and monitor until it fails. Do yall think that this would be helpful in our attempts to fix the firmware problems in 3.1?

I am willing to send this chip anywhere in the world at my own expense if it would help in this effort, once I have received the replacement chip and have verified that it is working and of the correct version.

Hey SMB784, Thank you for the proposal. That might become handy.
I have 2 FY6600 at the moment for tests, a 15Mhz and a 60Mhz version. I am willing to flash the 15Mhz with the new firmware as the idea is that this FY will turn into a dev model.
As you may have read, the CPU is protected and I will have to erase it. So I will then only have one official model that I will keep for test and reference. If something happen to this model, I will be clearly annoyed. I was thinking of replacing the CPU of the 15Mhz version with an empty one and keeping the official as a spare but if I can have an original spare without loosing time with desoldering/resoldering the CPU that would be nice...

[fremen67]

A good idea will be to see if we can use the latest FPGA image for older devices, I'm wondering what had happen with the 3.4.1 firmware version, did anybody encountered it again ?

 Cheers,
 DC1MC

Yes, I think this would be logical at some point to use the new FW with the latest FPGA version. Maybe not during the BP transition but later on when flashing the FP. Plus it will be easy to update. It might even be updated via a PC front end via the FP (with some risks though).

[soundtec]

That sounds like good news for owners of version 3.1 SMB784, its the first real acknowledgement we've had ,either from the supplier or the manufacturer that there was an issue with 3.1 . Is it a new front panel stm32 ic they are sending you ?

I finally went ahead and fitted the IEC connector , a mains Rf filter at the input separate from the psu board ,a grounded the metal screen between the psu and signal board and hooked  the power supply ground back to mains earth .
I had a chance to try it out over at a friends place today ,from a cold switch on the frequency was bang on to 6 digits throughout the range ,better than I thought it would be.

Im still not 100% happy with the interaction between the 5 volt and +/- 12 volts rails under load, so Im on the lookout for a small  5 volt supply .

Can anyone hazard a guess as to why Feeltech made the attenuation kick in at higher frequencies ,doesnt make much sense really ,and a way to get rid of it would be great .
 

[SMB784]

Hey SMB784, Thank you for the proposal. That might become handy.
I have 2 FY6600 at the moment for tests, a 15Mhz and a 60Mhz version. I am willing to flash the 15Mhz with the new firmware as the idea is that this FY will turn into a dev model.
As you may have read, the CPU is protected and I will have to erase it. So I will then only have one official model that I will keep for test and reference. If something happen to this model, I will be clearly annoyed. I was thinking of replacing the CPU of the 15Mhz version with an empty one and keeping the official as a spare but if I can have an original spare without loosing time with desoldering/resoldering the CPU that would be nice...

I would happily send the chip to you, but I would very much like it to be used to figure out what the mode of failure is for version 3.1.  would that be possible, in your opinion?

That sounds like good news for owners of version 3.1 SMB784, its the first real acknowledgement we've had ,either from the supplier or the manufacturer that there was an issue with 3.1 . Is it a new front panel stm32 ic they are sending you?

I actually have no idea what it is they are sending me, but we will find out when it arrives!

[cybermaus]

Well. V3.1 is not actually failing in any critical manner. It is V3.0 that is.

There is a rare report of losing the sine on 3.1, but that is fixable from the PC software, and only 2 people ever reported it.
On v3.0 however we have a half dozen people with completely unusable and un-fixable firmware.


It is very interesting to know how/where you got this promise for a new chip. That half dozen people may be interested to know. You'd still need some pretty good 0.5mm pitch chip de-soldering skills, but if the device is already broken there is little to loose.

[Scratch.HTF]

With regard to the fixed sampling clock for each DAC, there are two general purpose PLLs in the Altera EP4CE6 as used in the FY6600 (each DAC can have an independent PLL clock source in theory); for more information read Clock Networks and PLLs in Cyclone IV Devices at https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-iv/cyiv-51005.pdf
The PLL VCO in the EP4CE6 operates from 600 MHz to 1300 MHz which requires an input clock of 5-362 MHz (sourced from the 50 MHz timebase oscillator) as per the C8 suffix device used in the FY6600 and additional PLL specifications can be found at https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-iv/cyiv-53001.pdf
Within the PLL VCO range, 1250 MHz / 2 = 625 MHz which means we have a frequency block which can be divided by 2 which results in contiguous blocks e.g. 625-1250/125-250/62.5-125 etc.
All counters in the PLL chain are 16-bit and can be individually bypassed.

[DaveR]

Another 3.2 tester here happy to report that everything appears to be working well under Blue Pill control (once I'd remembered to plug the USB lead into the SG, anyway  ).

Thanks, fremen.  Standing by for future releases.

Dave

[spec123]

Residual FM or short-term jitter of FY6600.

Here is a comparison of short term jitter for three signal generators. Nominal frequency is 10.1398 MHz with each SG offset in frequency a small amount. Shown in the image is a spectrum waterfall (horizontal axis is frequency) with about 2 FFTs per second. Left trace is Marconi 20222D, center is FY6600 and right is cheap ($20) DDS AD9851. Jitter of FY6600 is estimated to be 5 to 6 Hz.

The large jitter in the FY6600 would seem to rule it out for use as a local oscillator in radio projects. Too bad, since many nice applications are based on small FM deviations such as WSPR with 1.46 Hz per symbol. 

Tried the FM modulation function of FY6600 with WSPR symbols programmed in Arbitrary waveform for CH2. It worked sometimes but message was lost most of the time.

Am I correct in assuming that the jitter problem for the FY6600 cannot be resolved?

FY6600 used for the test is new, never opened unit with FW version 3.2.

[doobs]

Hi,
I bought one of these recently. Up around 60MHz I've been having a bit of trouble getting a reliable external sync out of it. The pulses seem to vary in shape and magnitude like a distorted rectified sine wave.
Makes it a bit problematic trying to get a reliable trigger on me scope.

Doug

[DerKammi]

Which output are you referring to? Front panel output could benefit from different op-amps if really needed.

Back output won't be able to keep up with that high frequency due to a 74HC245 buffer which runs at typical 55 MHz max. so 60 is maxing it out pretty much.

[cybermaus]

Here is a comparison of short term jitter for three signal generators.
...
Am I correct in assuming that the jitter problem for the FY6600 cannot be resolved?

Wow, that looks pretty bad. What do you mean by "short term"? How much time does this waterfall cover?
One source of jitter that can be easily fixed is the 50MHz XO. Replace it with a better 50MHz TCXO or even a OXCO.

The other big source of known jitter is the mapping of the wave on the 250MHz DAC resolution, but I am not sure if that applies here, because you are doing sine waves?
What do you mean by "WSPR symbols programmed in Arbitrary waveform"? So you are not using sine?
Out of interest, could you produce the same waterfall on a 10.0000000MHz signal. That would eliminate the 250MHz, so we can see if indeed that does not apply here.


A third possible problem with your use case is that the FM modulation is done not by the FPGA, but by the STM32 CPU quickly and repeatedly telling the FPGA to change frequencies. So you would start getting problems with the CPU speed, the SPI bus speed, as well as the CPU jumping off to serve various interrupt routines.
But again, you seem to hint that you code your own FM into arb waves?

[rhb]

WSPR is a narrow bandwidth FSK mode used in amateur radio which requires a very stable clock, usually a GPSDO.  It was designed to allow measuring propagation over long distances with very low power. A search will turn up lots of information.  For WSPR to work properly the clock has to run at certain frequencies that allow creating the correct tone spacing.  There's a good explanation of the problem on the QRP-Labs website.

I think this is something Zov can fix when he gets back from vacation if there is enough unused real estate in the FPGA to add a PLL to generate the proper clock rates or by modifying the existing clock.

[spec123]

Re: FY6600-M60 jitter.

All three signal generators were set to sine wave without any modulation and were used simultaneously. Plot used 2 FFTs per sec or about 20 to 30  seconds. Don't remember exactly.

Yes, the jitter is pretty bad for the FY6600, about 5 to 6 Hz residual FM. I have repeated the test after frequency calibration and sine wave repair. Got exactly the same result.

I mentioned WSPR protocol since it uses 1.46 Hz per symbol for FM. There are 162 symbols in a message with each symbol having 0, 1, 2, or 3. The message is easy to program in an ARB waveform on FY6600. Then I used the ARB waveform on CH2  to FM modulate the sine wave on CH1. In spite of the bad FM jitter observed from above test, decided to try it anyway.  To my amazement it worked... once in a while ...but most of the time the message was not decoded. I attribute the fact that it was decoded at all as due to the robust WSPR protocol which uses forward error correction.

Anyway, I am very discouraged since I had hopes of using this SG for some radio experiments. None-the-less there are some features, like the variable phase output and dual outputs that will prove useful for some work.  My further reading on the subject seems to indicate that jitter is due to the way the DDS plays back an arbitrary waveform. Hopefully someone here can address this jitter problem, if it at all possible.

[Ebel0410]

Re: FY6600-M60 jitter.
Hopefully someone here can address this jitter problem, if it at all possible.

My opinion is that there will be no simple fix for the jitter problem, because it is inherent to the FY6600 electronic design.
Some of us described how the CycloneIV works with its internal PLL, and how the limits are reached.

The output signal, without any modulation applied (square or sine, it doesn't matter) is jitter free at specific frequencies like 1M, 2M...
I made some tests around 1MHz, there is no jitter at 1M, nor at 1.008375 MHz, 1.016065 MHz and so on. A bit Strange for me
BTW, in your case, to produce a very thin FSQ modulation, you need a carrier as stable as possible(smooth PLL feedback design).
The FY6600 is clearly not designed to provide FSQ modulation as sharp as you mentioned in your last post imho.

Regards
 

[Insatman]

Residual FM or short-term jitter of FY6600.

Here is a comparison of short term jitter for three signal generators. Nominal frequency is 10.1398 MHz with each SG offset in frequency a small amount. Shown in the image is a spectrum waterfall (horizontal axis is frequency) with about 2 FFTs per second. Left trace is Marconi 20222D, center is FY6600 and right is cheap ($20) DDS AD9851. Jitter of FY6600 is estimated to be 5 to 6 Hz.

The large jitter in the FY6600 would seem to rule it out for use as a local oscillator in radio projects. Too bad, since many nice applications are based on small FM deviations such as WSPR with 1.46 Hz per symbol. 

Tried the FM modulation function of FY6600 with WSPR symbols programmed in Arbitrary waveform for CH2. It worked sometimes but message was lost most of the time.

Am I correct in assuming that the jitter problem for the FY6600 cannot be resolved?

FY6600 used for the test is new, never opened unit with FW version 3.2.

I ran the same test on my modified FY6600.  The oscillator has been swapped to a TCXO 1ppm unit.  see post https://www.eevblog.com/forum/testgear/feeltech-fy6600-60mhz-2-ch-vco-function-arbitrary-waveform-signal-generator/msg1434962/#msg1434962.   Also my power supply has had the output capacitors replaced with Rubicon low ESR types.  A 100nF X7R ceramic capacitor was added on the bottom of the board on each of the three rails.   These PS mods, plus a lossy ferrite on the power jumper does a lot to get rid of the nasty switching spike on the DC power supplies. 

The data shown below was taken on my SA at 3Hz RBW.   I can see no significant short-term jitter in the signal on the SA or on my Frequency counter.   Frequency drift over several hours was previously observed at ~0.3ppm (10.0MHz). 

The oscillator only costs $11 from Digikey and is relatively easy to install.  Well worth it.

[fremen67]

Problem connecting to the site from France today   

Here is a new Version of PC Software and Firmware for BP (v0.4).
I added a configuration tab where you can activate the Over-Voltage protection and choose the range mode from Automatic / Low Range / Mid Range / High Range. This will allow to study the frequency response for each range.
I also removed for now the amplitude limitation to 5V after 20 Mhz.

The idea now is to gather information to:
- allow the best software calibration of Offset and Amplitude in the 3 ranges
- Find the best thresholds for switching ranges (now +/- 0.25V and +/- 2.5V) depending on waves... or not...
- Find the best thresholds for switching ranges for DC (works with Offset) if different from above
- Find the best frequency limits for each wave type
- Find whatever could be usefull ...

I will program what you think is the best configuration. Up to you! 

I was also thinking about adding a 50 Ohms mode (at least for mid and high range as low range is not 50 ohms). Or maybe a user defined load if you think it is usefull...

While waiting for feedbacks, I will work on configurations Back-up & Restore