Thank you sountec for the feedback!
Yeah thats working a lot better for me , I see the ok/encoder push now defaults each variable to a preset value thats great in offset , phase ,duty and rise /fall , my question is would it be simpler to make the default values the same as power on values?
This was already existing in the previous versions. As you noticed, this was meant to reset parameters to preset values like offset (0V), phase(0°), duty(50%) and rise/fall(4ns) . For frequency and amplitude that might be less usefull as frequency = 10kHz and amplitude = 2.5 V. These are the default power on values when the "last power on values" option is not checked. It is of course possible to take last power on values when pushing OK but then you have to remember what the values were, plus if you don't use the option, M1 memory, which is used to store the values when powering off, could be empty or could contains values that you don't even remember…
So you might be in a situation where you are not sure of what will happen when pushing a button...
One thing I like about your BP version is the addition of the numeric keypad , I think when you look and compare the FY series to the better makes of stuff thats the big difference , the Rigols and the Owons have a slightly bigger box to encorporate the numberpad .
The photo of the bluepill setup I posted might be confusing. I use a numeric keypad on the bluepill just because I needed a 4x4 matrix keypad to replicate the front panel keyboard hardware. Each key of the numerical keypad corresponds to an existing FP key (F1 = 1, F2 = 4, …). It is not used for numerical data input.
I did notice that the data from the counter was only displayed when triggered from software , engageing counter from front panel the software wasnt able to hook in , also software reported back 10khz or ten times the value displayed on the unit itself .
The PC software is not reading continuously values and configuration from the FP. This of course possible but it consumes CPU times of the FP to get messages and to reply to them. This could lead to create artefacts when the FP is sweeping waveforms, which is done 100% by the FP software (FPGA genarates the wave and the FP sweeps it).
The only exception is when you trigger the measure function from the PC Software as it has obviously to read the measure values from the FP.
If you mix data input (on the FP directly and on the PC Software) you could then have inconsistent values displayed on the PC software.
For example if you change the gate time directly on the FP and have the PC Software reading measures, the frequency will not be displayed correctly unless you force a refresh of all the values (changing to another tab and coming back now forces a values refresh in the 0.82).
If you need to modify values on both the FP and the PC Software, then you have to think of forcing a refresh manually on the PC Software at some point.
I still see some waveform corruption in the display for the sine wave ,as loaded on slot one ,it sorta has a tail on it ,visable on the unit itself and also on the software
As I explained previously, this comes from a corruption of your sine directly in the main board eeprom. This is a known bug of the FY6600 caused by the FPGA. The only cure is to write the sine definition again in the eeprom. Either with an external programmer or using the FP to do it, which is what feeltech did (this function not developped yet in the FP).
The workaround for now is to use an arb slot with a sine wave that you send from the PC Software.
now in 0.82 pc Im seeing two cycles of each wave displayed in the thumbnail view in control window .
Yes it was already like this in the previous versions. This might not be a good idea but I found it easier to read for some waves, like ramps for example. As for the FP LCD, it only displays on cycle.
Just as a test I applied factory square wave (slot2) to measurment input , 1khz 5 volts ,all other parameters default , I get back a reading of 49.9 duty and differing +/- peak widths , 499,992 /500,008 and its a bit jumpy ,
I went ahead and created my own square wave in the software ,uploaded it to a blank arb memory slot , comes out perfectly 50% duty and right on 500,000nS and 1khz ,rocksolid
Ill repeat the same test with the unmodified FY6800 next and compare the result . Could it be possible that even the original memory slots data are corrupted to some small degree and that discrepency somehow got worse ,maybe .
The square wave, but also CMOS and Adj-Pulse waves are not stored in memory slots. They are dynamically created by the FPGA. It would otherwise be impossible for it to adjust on the fly the duty cycle for them (or pulse length).
When using a square wave that you created in a memory slot, the FPGA just send it to the output. This is a different process, hence the different results you got.
Unfortunately even a new FP firmware can't change this.
Another thing about the measure page was gate mode isnt initially set, maybe just default to 1 second mode like the original software here might be best as I think it causes the pc software to hang up a bit as it expects to see a signal .
I guess you still have inconsistent values in M1 from 0.81 and still have "last power on option " checked. This should be fixed after you corrected those values and switch off the FY6600.
You could otherwide perform a factory reset (which I recommand), but it will reset calibration data if you changed them, or you could simply check all the values and save your configuration to M1.
So I repeated my test with the standard FY6800 , around 499,994 vs 500,006 was the best I could get , regardless of uploaded/internal waveform , ac or dc coupled input . I did generally see an improvement across both AC and DC measurements with the new waveform , maybe someone else can try the same test .
I guess you saw 499,996 and 500,004 ns as they are multiples of 4ns.
4ns is the minimal resolution of the FY6600 and FY6800 as they sample at 250 000 Msa/s. So that seems quite logical results...
Sorry for the long post but I though this might also have some kind of interrest for others…
EDIT: 49.9 % is an incorrect rounding of the duty cycle. It should display 50.0 % as the result with a cycle of 1,000,000 ns and a wide+ of 499,992 ns is 49.9992 %. I will correct it in the next version.
And by the way 499,992 ns instead of 500,000 ns represents an error of 0.0016 % … I don't think the FY6600 oscillator is that precise...
Home
Help
Search
Login
Register
