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

[Kaku]

Not a SPI guy myself. But some suggestions:

- Lay your wire nice and straight, no spaghetti
- Short wires, no loops, and close together, keep the rainbow-ribbon whole if possible

My BP wiring is short, last night made veroboard construction.


 

[DerKammi]

You need better grounding, the signals are floating in air and don't have a proper return path with this vero board layout.

Use copper tape under the wires and connect all grounds to this copper tape. If you don't have copper tape then please twist the signal wires with a ground wire.

I'm am doing this this evening hopefully as my spaghetti wiring is making things going haywire.

[cybermaus]

Strictly speaking true, but seems overdone. His veroboard is already 10x nicer then my wires, even if I did lay them straight.
So, I don't know, check for bad soldering connections ?

Anyway, today is a busy day, I should tell myself to stop checking this forum.

[DerKammi]

I can agree with you but my experience does show different. Loose wire does sometime work better than veroboard. Not always but it does happen. Twisting signal wires with ground does help in a massive way in the MHz range.

[Kaku]

MISO signal is a source of BP problems. Small capacitor (470pf)  to gnd and BP always works. If you have an oscilloscope, check the  signal from your device. You should also look at the signal from the original front panel, it is very bad.

[fremen67]

MISO signal is a source of BP problems. Small capacitor (470pf)  to gnd and BP always works. If you have an oscilloscope, check the  signal from your device. You should also look at the signal from the original front panel, it is very bad.

Well done

Did you notice any update problem with modified PC Software on startup?

I will also define unused I/O pins as output and set them to 0 (except PB0 which is better to keep as an input). This should also increase BP noise immunity.
We may also add the 2x 300 ohms resistors in serial with TX and RX as it is done in the original Feeltech design (At least I think it is, DerKammi could confirm that.). Not sure this will help a lot for noise but at least this would be identical to original design.

I will try to release version with output pin modification this evening.
Unfortunately busy week at work and at home..

[DerKammi]

We may also add the 2x 300 ohms resistors in serial with TX and RX as it is done in the original Feeltech design (At least I think it is, DerKammi could confirm that.). Not sure this will help a lot for noise but at least this would be identical to original design.

They are there on the main board to the connector already, I also don't think there is a problem on the serial side.

[Kaku]

Did you notice any update problem with modified PC Software on startup?

Update problem? I do not really know what you mean? I have not noticed any problems.

[fremen67]

Did you notice any update problem with modified PC Software on startup?

Update problem? I do not really know what you mean? I have not noticed any problems.

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

Default values when starting BP are the one you can see on the screenshot here:
https://www.eevblog.com/forum/testgear/feeltech-fy6600-60mhz-2-ch-vco-function-arbitrary-waveform-signal-generator/msg1441974/#msg1441974

[Kaku]

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.

[ArthurDent]

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.

[Ewald1963]

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

[DerKammi]

Well, finally tested the 0.2 version. And it does work nicely thus far. But not on both devices I have.

My own works fine but Mark his unit isn't listening to the BP. When operated with the FP all is fine. Not sure where to start trouble shooting.

[cybermaus]

Just a though: That was a a broken V3.0 unit, right?

It is possible the FPGA has smaller or larger changes between the versions, and thus it is possible you need to match FPGA firmware with STM32 firmware. For all we know, they made a small but significant change to the SPI protocol. Maybe you need to bring the FPGA to V3.1

What version did Fremen69 use to develop?

[DerKammi]

Both are 3.2 I'm afraid

[fremen67]

Well, finally tested the 0.2 version. And it does work nicely thus far. But not on both devices I have.

My own works fine but Mark his unit isn't listening to the BP. When operated with the FP all is fine. Not sure where to start trouble shooting.

Do they have both a modded power supply? Otherwise you could try swapping the mainboards ...

[DerKammi]

Also the same. Clock is running at the DAC but no data.

[zov]

Just a though: That was a a broken V3.0 unit, right?

It is possible the FPGA has smaller or larger changes between the versions, and thus it is possible you need to match FPGA firmware with STM32 firmware. For all we know, they made a small but significant change to the SPI protocol. Maybe you need to bring the FPGA to V3.1

What version did Fremen69 use to develop?

Indeed, configurations of FPGA for different version has been changed. I have checked it comparing flash contents for V3.1 and V3.2. They differ in FPGA configuration data part of them.

[fremen67]

Also the same. Clock is running at the DAC but no data.

Just a though: That was a a broken V3.0 unit, right?

It is possible the FPGA has smaller or larger changes between the versions, and thus it is possible you need to match FPGA firmware with STM32 firmware. For all we know, they made a small but significant change to the SPI protocol. Maybe you need to bring the FPGA to V3.1

What version did Fremen69 use to develop?

Indeed, configurations of FPGA for different version has been changed. I have checked it comparing flash contents for V3.1 and V3.2. They differ in FPGA configuration data part of them.

Swapping the boards (or the FP) will show any compatibility problem between version.

The reverse engineering has been done on a V3.2 version. We know that BP is also working on V3.1 (cybermaus for example).
We have no clue right now if it is working on other versions.

Should it be the case, I would need a V3.0 dump to test it.

I compiled a new FW version with all unused Pins configured as outputs. It would be interresting to see if it improves noise problems..

I think I will add another functionnality that would be interresting for testing: the possibility to have a fixed output range. This will allow exploring the full output ranges at different frequencies, thus finding the best thresholds for switching the outputs.
This function will also be usefull later on if you don't want relays switching during your tests.

[DerKammi]

I'll try to read out the flash chip thus evening to see whether I have differences.

[DerKammi]

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

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.

[DC1MC]

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

[tek2232]

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 !

[cybermaus]

I think I will add another functionality that would be interesting for testing: the possibility to have a fixed output range. This will allow exploring the full output ranges at different frequencies, thus finding the best thresholds for switching the outputs.
This function will also be useful later on if you don't want relays switching during your tests.

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.

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.

This is not exactly what you asked about of course, but related and I was reminded of it.
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.

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 ?

I think you mean 3.2.1. That was reported once, but I do not remember a 3.4.1
Its easy to experiment with that. We can flash the Winbond all we want. But no-one ever published 3.2

[zov]

We can flash the Winbond all we want. But no-one ever published 3.2

fremen67 did https://www.eevblog.com/forum/testgear/feeltech-fy6600-60mhz-2-ch-vco-function-arbitrary-waveform-signal-generator/?action=dlattach;attach=389282