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

[texaspyro]

You REALLY don't want to be using a logic analyzer that samples the signals asynchronously.  You want one where the data lines are clocked in by the SPI clock (preferably qualified by chip select).  That way you only transfer data that is relevant and at a 18 MHz max data rate. 

If you have an analyzer with enough channels, maybe build a shift register front end and clock the whole (48-bit?) transfer into it and have the analyzer grab those.

[DC1MC]

You REALLY don't want to be using a logic analyzer that samples the signals asynchronously.  You want one where the data lines are clocked in by the SPI clock (preferably qualified by chip select).  That way you only transfer data that is relevant and at a 18 MHz max data rate. 

If you have an analyzer with enough channels, maybe build a shift register front end and clock the whole (48-bit?) transfer into it and have the analyzer grab those.

In theory it works, in practice not so much, we need here the temporal information as well and unfortunately not all the operations are 3 x16bits over one CS low, the read transfers are first transfer register address follower by one or more 2x16bits per CS low value read operations. So IMHO, no way around a good minimum 50MHz sampling, RLE and streaming LA.

But if you have the FY6600, you can give it a try and post some captures, I will decode them for you, start with short message, like value changes that are just 20-21 register operations.

 Cheers,
 DC1MC

[texaspyro]

For the protocol decoding, I doubt you need any temporal data.   You just need the data that is transferred.  Also, you could use just an 8-bit shift register... that would cut the data rate down quite a bit.  I've been using logic analyzers and protocol decoding for over 40 years.  Unless there is something silly going on with the FY6600,  using an asynchronous capture mode is the wrong way of going about it.

I don't have a FY6600 to test, or time to do it if I had one.

[DC1MC]

Hello everybody, quick update for the startup sequence, it mostly consists of endless reads, WITHOUT sending an address, the readback values are some times a string off zeros or a string of 0x00000001.

Fremen67, guys, you're still around, not much activity over WE .

 Cheers,
 DC1MC

[DerKammi]

The unit is finally in Holland. So yes pretty quiet Need it on the doorstep....

[gbraux]

Hi. I am new to the forum, so a big hello from Paris, France.

I have just received my FY6600 (30Mhz) from Aliexpress and ... looks like they have updated the PSU :-)
I also ordered some IEC connectors at the same time ... but I won't bother making the ground hack : Ground-BNC to Ground-Earth = 300mV :-)

Did you measure AC or DC?

Oups ! My bad, was measuring DC ... now measuring 84V AC  :-(
Just added an IEC plug (and as the ground connector is not there anymore on the refreshed PSU, I directly soldered earth-ground to the back of the PCB).

[rhb]

I think my SB may windup inside the GDS-2072E  Just need the proper signals and a map of the state machine.  Integrating it with the GDS-2000E software is more work, but preferable in the long run.  One could do a lot of cool stuff with the addition of a GPSDO timebase.  Full measurement  up to 6 M for under $400?  Not bad.  But I think I'll buy a JDS for regular use unless someone comes up with a way to reflash the FT devices with a usable image.

[fremen67]

Fremen67, guys, you're still around, not much activity over WE .

Well this is not exactly what I would say.

I decided this Saturday evening to have a one hour session on the FP-FPGA protocol decoding to see what I could find. What happened to me was worse than being attracted by a black hole. My last two evenings where long… my last to nights were short. This thing is more addictive than drugs.
First I decided to add the nor flash into the game. Cybermaus already explained precisely how it was organized, containing the predefined waveforms and the arbitrary waveforms as well. As I did a backup of the flash, I already had the header pins soldered. A quick check at the Flash_CLK pin showed that it was running @ 20Mhz. So definitely a separated SPI bus that has to be connected to the FPGA. Five pins connected later, and after adding a second SPI protocol in the LA configuration, I was able to see the flash talking synchronized with the FPGA-FP telegrams when switching waveforms. So far so good. But that was just the beginning of the black hole thing… Long story short..The service telegrams are now decoded  (containing mode, state, setpoints of CH1&CH2) and the Read mechanism from Flash to FPGA, From Flash to FP and Write from FP to Flash is now clear, that is:
1-   Direct transfer requests of waveforms from Flash to FPGA (FP don’t see the values)
2-   Read requests from flash to FP, FPGA being a letter box
3-   Write requests from FP to flash, FPGA being again a letter box (when using the PC software)

All the captures I made showed a combination of those mechanisms in Power On, ON/OFF, waveform selection, setpoint modification telegrams.
There is also a specific telegram when in Measure Mode but it is much simpler and smaller, for reading counter, frequency and the 2 half parts of a cyclic input signal.
You will find attached a description overview of the registers, new ones, some of them still to be identified, others already identified by DC1MC who also already explained the register write mechanism.
With this file, every one should be able to decode almost all the messages that we captured. The main missing registers are used during the power ON sequence, I suppose for initialization purposes but no clue for them at the moment.

I will post some other documents later on too that might help understanding the mechanism and will also try to explain more precisely the read/write protocol.
Not sure how long I will stay awaken ...
Enjoy!

Hello everybody, quick update for the startup sequence, it mostly consists of endless reads, WITHOUT sending an address, the readback values are some times a string off zeros or a string of 0x00000001.

Should be crystal clear now...

[SMB784]

Fremen67, guys, you're still around, not much activity over WE .

Well this is not exactly what I would say.

I decided this Saturday evening to have a one hour session on the FP-FPGA protocol decoding to see what I could find. What happened to me was worse than being attracted by a black hole. My last two evenings where long… my last to nights were short. This thing is more addictive than drugs.
First I decided to add the nor flash into the game. Cybermaus already explained precisely how it was organized, containing the predefined waveforms and the arbitrary waveforms as well. As I did a backup of the flash, I already had the header pins soldered. A quick check at the Flash_CLK pin showed that it was running @ 20Mhz. So definitely a separated SPI bus that has to be connected to the FPGA. Five pins connected later, and after adding a second SPI protocol in the LA configuration, I was able to see the flash talking synchronized with the FPGA-FP telegrams when switching waveforms. So far so good. But that was just the beginning of the black hole thing… Long story short..The service telegrams are now decoded  (containing mode, state, setpoints of CH1&CH2) and the Read mechanism from Flash to FPGA, From Flash to FP and Write from FP to Flash is now clear, that is:
1-   Direct transfer requests of waveforms from Flash to FPGA (FP don’t see the values)
2-   Read requests from flash to FP, FPGA being a letter box
3-   Write requests from FP to flash, FPGA being again a letter box (when using the PC software)

All the captures I made showed a combination of those mechanisms in Power On, ON/OFF, waveform selection, setpoint modification telegrams.
There is also a specific telegram when in Measure Mode but it is much simpler and smaller, for reading counter, frequency and the 2 half parts of a cyclic input signal.
You will find attached a description overview of the registers, new ones, some of them still to be identified, others already identified by DC1MC who also already explained the register write mechanism.
With this file, every one should be able to decode almost all the messages that we captured. The main missing registers are used during the power ON sequence, I suppose for initialization purposes but no clue for them at the moment.

I will post some other documents later on too that might help understanding the mechanism and will also try to explain more precisely the read/write protocol.
Not sure how long I will stay awaken ...
Enjoy!

Hello everybody, quick update for the startup sequence, it mostly consists of endless reads, WITHOUT sending an address, the readback values are some times a string off zeros or a string of 0x00000001.

Should be crystal clear now...

That is some excellent work there, Fremen!

I just got my device in the mail today, and I just found out that it is version 3.1.

With that being said, in light of Fremen67's work, can we get an update on what still needs to be done?  What tasks are left, and what unknowns still exist?  I would like to contribute, but I don't yet know what I should be doing.

[fremen67]

With that being said, in light of Fremen67's work, can we get an update on what still needs to be done?  What tasks are left, and what unknowns still exist?  I would like to contribute, but I don't yet know what I should be doing.

There are still some registers to discover (I just realized I forgot to update my document with Reg 0x37... for the next time).

Registers definition are the keys to understand what is done on a macroscopic point of view. To move on, we need now to have a macroscopic description of what is done by the FP for each possible action on the FP.

A macroscopic description would be: "When changing the frequency on a sine wave, the FP sends a service telegram which includes: modulation status , CH1&CH2 offsets, ..." rather than: "When changing the frequency on a sine wave, the FP writes reg0x1D, Reg0x24, Reg0x2B, Reg0x2C, ...."

Another example: If you select a new Sine waveform, you could describe it this way:
"The FP:
1 - Reads CH2 waveform from flash
2 - Reads CH1 Waveform from flash
3 - Wait about 58ms
4 - Sends a service telegram with modulation status, ...
5 - Request the FPGA to read a sine waveform from the Flash
6 - Sends a service telegram with output status, ..."

This would the base for a new FP program.

[fremen67]

@DC1MC
You will find attached the files you requested (plus some extra).
For the waveform loading captures on CH1, I selected ARB63 on CH2. This is an empty waveform, which eases the analysis (you will notice with MISO from FP SPI). It  is also stored in Flash so you will see CH2 transfer).

There is definitively something strange with the TRGL waveform :
- When switching from DC to Triangle, The FP reads CH2 waveform, than CH1 waveform (that is TRGL) from flash but does not request FPGA to update its waveform from flash
- When switching from Ramp to Triangle, The FP reads CH2 waveform, than CH1 waveform (that is TRGL) from flash AND does request FPGA to update its waveform from flash (you see the transfert)

I wonder if it's a new behaviour on v3.2 or if it's already like that on V3.1 ...

The other waveform loading captures also show which are in flash and which are not.

The duty cycle modifications on a square waveforms look very interesting!

Good luck. You will see that the flash SPI under the other signals will change your live 

[DC1MC]

Fremen67, guys, you're still around, not much activity over WE .

Well this is not exactly what I would say.

I decided this Saturday evening to have a one hour session on the FP-FPGA protocol decoding to see what I could find. What happened to me was worse than being attracted by a black hole. My last two evenings where long… my last to nights were short. This thing is more addictive than drugs.
First I decided to add the nor flash into the game. Cybermaus already explained precisely how it was organized, containing the predefined waveforms and the arbitrary waveforms as well. As I did a backup of the flash, I already had the header pins soldered. A quick check at the Flash_CLK pin showed that it was running @ 20Mhz. So definitely a separated SPI bus that has to be connected to the FPGA. Five pins connected later, and after adding a second SPI protocol in the LA configuration, I was able to see the flash talking synchronized with the FPGA-FP telegrams when switching waveforms. So far so good. But that was just the beginning of the black hole thing… Long story short..The service telegrams are now decoded  (containing mode, state, setpoints of CH1&CH2) and the Read mechanism from Flash to FPGA, From Flash to FP and Write from FP to Flash is now clear, that is:
1-   Direct transfer requests of waveforms from Flash to FPGA (FP don’t see the values)
2-   Read requests from flash to FP, FPGA being a letter box
3-   Write requests from FP to flash, FPGA being again a letter box (when using the PC software)

All the captures I made showed a combination of those mechanisms in Power On, ON/OFF, waveform selection, setpoint modification telegrams.
There is also a specific telegram when in Measure Mode but it is much simpler and smaller, for reading counter, frequency and the 2 half parts of a cyclic input signal.
You will find attached a description overview of the registers, new ones, some of them still to be identified, others already identified by DC1MC who also already explained the register write mechanism.
With this file, every one should be able to decode almost all the messages that we captured. The main missing registers are used during the power ON sequence, I suppose for initialization purposes but no clue for them at the moment.

I will post some other documents later on too that might help understanding the mechanism and will also try to explain more precisely the read/write protocol.
Not sure how long I will stay awaken ...
Enjoy!

Hello everybody, quick update for the startup sequence, it mostly consists of endless reads, WITHOUT sending an address, the readback values are some times a string off zeros or a string of 0x00000001.

Should be crystal clear now...

Holly rotating cow on 3D gymball, fremen67 are you a younger version of me  ?!?!  I remember ca 35 years ago disassembling the Sinclair Spectrum ROM with just a pencil, a paper notebook and bootleg copy of Z80 manual. Painful, but somehow you wake up  in an excellent mood, better than the other thing

That's a real effort here people, the WE silence was bringing us so much stuff, thank you so much, chapeau bas  . I was coming very late yesterday from the Arbeit, and only this morning I had a look at the headmounted glasses post responses, and observed that  there is one more post in the FY6600 topic and casually looked on it, and by Jove, now I have to take  some hours off !!!

One quick thing about the register 0x25 (50 million) and 0x26 (500million), they seem to be correlated with the 50MHz oscillator that is used as timebase, in a joyful future we may be able to replace it with a stable 10MHz source, and if these are the only modifications, jackpot  !!!  Most likely they are just time base for the frequency measurement, but one can dream .

I would look in to the triang waveform, can you switch sometime form sine to triang, to see it this time at least it updates the waveform in RAM, or it could be as well yet another bug from our FeeTech guys.

The common measurement along with the flash SPI was really perfect, we need to see edges, where this shitty fw screws thing. I'm really curious where in the MCU firmware are writing operations, because I can understand screwing up the external flash, but I don't understand what had happened with the internal one ?!?!?

What we need now:

 - Blue pills board to do a quick serial-to-SPI converter, I'm curious if the Dupont pins are fitting there, then there is no need for connector.
 - A set of basic routines, I'll list them there for reference:
 = Wait_For_Ready.
 = Writer_register
 = Set_Register_Address
 = Read_Register
 
And then one level higher routines:
 Set_Freq
 Set_Level
 Set_Offset
 Set_Phase
 ---
 and so on
(for the development purposes, these can be emuleted for the moment in a PC program that discuss with the blue pill via serial)

And of course the telegrams ( I like this word, better thane the messages that I was using)


If we get some good news form the members that promised to extract the schematic, we can focus afterwards on how the LCD is driven and see if in the yuuuge library collection from STM there is something compatible, and get rid of the ugly fonts  .

Also in the end ( I have now to run ), it would be sooo nice to have a member with a 30MHz or lower device, trying to program the 59.999 MHz , revenge at last 

 Cheers,
 DC1MC

[fremen67]

Holly rotating cow on 3D gymball, fremen67 are you a younger version of me  ?!?!  I remember ca 35 years ago disassembling the Sinclair Spectrum ROM with just a pencil, a paper notebook and bootleg copy of Z80 manual. Painful, but somehow you wake up  in an excellent mood, better than the other thing

Younger ... well... as I also remember having done the same kind of stuff on the ZX81 (the model before the Spectrum) in 1981, that is ca 37 years ago, (and I also had the same tools  ) you could also be the younger one 
I am pretty sure that I still have the ZX81 with the original manual and some tapes somewhere in the attic...

I would look in to the triang waveform, can you switch sometime form sine to triang, to see it this time at least it updates the waveform in RAM, or it could be as well yet another bug from our FeeTech guys.

No problem when switching directly from Sine to Triangle, it updates the waveform in RAM.

What we need now:

 - Blue pills board to do a quick serial-to-SPI converter, I'm curious if the Dupont pins are fitting there, then there is no need for connector.
 - A set of basic routines, I'll list them there for reference:
 = Wait_For_Ready.
 = Writer_register
 = Set_Register_Address
 = Read_Register
 
And then one level higher routines:
 Set_Freq
 Set_Level
 Set_Offset
 Set_Phase
 ---
 and so on
(for the development purposes, these can be emuleted for the moment in a PC program that discuss with the blue pill via serial)

I have a STM32 dev board that I used some years ago. It may even be the same CPU as the FP. I will hock it and try to send some SPI commands. I would like to check the read sequence with CS RS. I will try with Reg0x18 (cyclic flash status update) as it seems to be the easier to begin with.

Cheers!

[DC1MC]

@fremen67 OK then, I'm the low energy youngster then  .

Nice work with the triangle wave, then it's yet another bug form FeelTech.
I'm also wondering if those really insane repetitions are really needed, the endless repetitions of all the parameters for the slightest change and so on, I have a feeling that the SB programming can be streamlined a lot, this we'll also help if we're gonna improve the seeping function.

What can I say, I'm humbled, keep up the good work, if you'll be able to communicate with the SB you'll be our hero, I  came so drained form the day job and this endless gray sky it's sapping the rest of the what little energy remains . But I'll push myself to see this to the end.

 Cheers,
 DC1MC

[fremen67]

Quick update of preliminary service telegram tests:

I hooked up a STM32 dev board directly to the Signal board on the FY6600 and was able to change frequency and amplitude 

That is just a proof of concept but this is very encouraging.
The test was as follows:
- FY6600 powered on, CH1 ON and connected to a scope, sine @10Khz and 5V amplitude, LA still connected
- I disconnected the ribbon  from the FP and connected directly my dev board to it
- I downloaded the first test program to the dev board: service telegram with modified frequency @20Khz and ... bingo! 20khz on the scope.
- Second test with a modified Amplitude à 2.5V and bingo again !! 2.5V Amp on the scope.
Attached a photo of the setup, 2 functions of the test program and the first LA capture of an alien processor fooling the FPGA
I think I will sleep well 

Code: [Select]

void test_service_telegram(void)
{
  fpga_write_register(0x1D,0x00,0x02);
  fpga_write_register(0x24,0x00,0x10);
 
  fpga_write_register(0x2B,0x00,0x7FF);
  fpga_write_register(0x2C,0x00,0x7FF);

  fpga_write_register(0x06,0x00,0x80);
  fpga_write_register(0x06,0x00,0x80);

  fpga_write_register(0x2D,0x00,0xE65); // 5.00V
//  fpga_write_register(0x2D,0x00,0x732); // 2.50V
  fpga_write_register(0x2E,0x00,0x00);

//  fpga_write_register(0x02,0x03,0x0D40); // 20kHz
  fpga_write_register(0x02,0x01,0x86A0); // 10Khz
  fpga_write_register(0x01,0x00,0x00);
  fpga_write_register(0x04,0x01,0x86A0);
  fpga_write_register(0x03,0x00,0x00);
 
  fpga_write_register(0x2F,0x01,0x00);
  fpga_write_register(0x30,0x01,0x00);

  fpga_write_register(0x05,0x00,0x20);
  fpga_write_register(0x38,0x7FF,0xDFFF);
  fpga_write_register(0x39,0x7FF,0xDFFF);

  fpga_write_register(0x08,0x0F,0xFFFF);
  fpga_write_register(0x09,0x0F,0xFFFF);
  fpga_write_register(0x37,0x00,0x01);
  fpga_write_register(0x37,0x00,0x00);


static void fpga_write_register(uint16_t chRegister, uint16_t chDataMSW, uint16_t chDataLSW)
{
  __FPGA_DC_CLR();
  __FPGA_CS_CLR();
  __FPGA_WRITE_WORD(chRegister);
  __FPGA_DC_SET();

  __FPGA_WRITE_WORD(chDataMSW);
  __FPGA_WRITE_WORD(chDataLSW);

  __FPGA_CS_SET();

} 


[beanflying]

Cant seem to remember front side shots of the FP. Wonder what K8 did? Wonder also what chip is hiding on the lcd......

Switch is connected to PB6 on the STM btw

[DerKammi]

@fremen67 great news, nice effort. Looking good so far.

I think the LCD is a standard ILI9340/ILI9341 chip one. These are used very widely. Libraries are no issue for these.

My unit is available for pickup today, hope to get some schematics done next week.

[beanflying]

Forgot to add my FP PCB was 'packed' with two washers to allow a couple of the switches to not be closed when the nuts were done up  properly

[Diabolo]

Hello,

The K8 switch has the same function when the rotary encoder button is pressed.
Feeltech deliberately destroyed the K8 switch to prevent deformation of the facade.

Diabolo

[DC1MC]

@fremen67 you're our hero, you deserve a good rest, better than this can't be.

Now I'm wondering two things:

 1) Is it really necessary to send a full telegram to change one parameter, what about just sending the SetFrequecy sequence and see if just the frequency changes ? If we can send the parameters individually, that will make a kick-ass sweeping generator /wobbler/antenna analyzer  .

 2) What about programming 65.200MHz, what it's actually the upper limit of the sine wave, hopefully someone with a 30MHz unit will chime-in and try to program 69MHz on it, if it works I have a feeling that the 30MHz cheaper ones will disappear abruptly  .

 Best regards,
 DC1MC

[fremen67]

I think the LCD is a standard ILI9340/ILI9341 chip one. These are used very widely. Libraries are no issue for these.

Yes that is also my first bet. It definitively has to be widely spread ans cheap. Once the FP schematic is ready, this should be easy to check.
If it's not the ILI9341, there won't be a lot more to check.

[fremen67]

1) Is it really necessary to send a full telegram to change one parameter, what about just sending the SetFrequecy sequence and see if just the frequency changes ? If we can send the parameters individually, that will make a kick-ass sweeping generator /wobbler/antenna analyzer  .

 2) What about programming 65.200MHz, what it's actually the upper limit of the sine wave, hopefully someone with a 30MHz unit will chime-in and try to program 69MHz on it, if it works I have a feeling that the 30MHz cheaper ones will disappear abruptly  .

This will be very easy to check but I first have to code the initialization sequence in the dev board because switching the SB from FP to dev board when everything is powered ON is really not the way to go .

[DerKammi]

Always nice having a new unit to play with and it stops with a Feeltech logo at boot (Feelbad)

Then off course opening the unit to plug in the FPGA ribbon connector and everything is Feelgood. Strange quality control these guys have

[Specmaster]

Always nice having a new unit to play with and it stops with a Feeltech logo at boot (Feelbad)

Then off course opening the unit to plug in the FPGA ribbon connector and everything is Feelgood. Strange quality control these guys have

Well it passed the test bench OK, whats the matter with that? It just took the quicker route to you by bypassing the tester 

[beanflying]

Always nice having a new unit to play with and it stops with a Feeltech logo at boot (Feelbad)

Then off course opening the unit to plug in the FPGA ribbon connector and everything is Feelgood. Strange quality control these guys have

Very thoughtful of them. Just getting it ready for you to start adding jumpers for hacking