Correct, they are NOT continuously variable. It recognizes only the pulse widths documented, and “rounds” a q-pulse command one way or the other to one of the defined widths.
LOL I see your discrepancy in defined pulses. I was sure this was a mismatch in variants like E2 vs E but both say right there… YDFLP-60-M7-L1-R.
Actually, I think I CAN explain this. JPT told me they had to have my source’s serial number, not just the exact model number, to give me the correct datasheet. I thought that was because they didn’t want their datasheet being given to a competitor, but they said they actually changed some of the operating parameters WITHIN a model run, without incrementing the model number. So your text info vs chart could be that.
I had to wonder- JPT M7 indeed recognizes ONLY the q-pulse sizes listed. If you drive a width other than listed, say 8ns and 12ns are defined but you give 10ns, it has to be rounding to either the 8ns or 12ns. I don’t know how it selects. It could be rounding high, or rounding low, or rounding from approx the middle.
I have to note that if it was strictly round-high or round-low, then a controller giving it exactly 8ns might actually not meet the cutoff for an 8ns pulse. And we don’t know which way the rounding goes so you might get the 6ns or 12ns q-pulse. Let’s see… the logic inside the machine will see the q-pulse command start a timer, and if the pulse is still high as the timer reaches 6ns, all we know is it wasn’t a 2ns or 4ns pulse. I’d want to design it to execute the defined q-pulse as soon as possible for precision uses. Hmm, still no indication how the cutoff time might be. It would be precision to start executing one of the predefined q-pulse routine as soon as the input goes from high to low. If the internal timer clocks that as 8.32ns from when it went high, I don’t know how this works.
Does it actually initiate something physical in the seed as the q-pulse starts with low-to-high? If so, then once the counter crosses 8ns, then clocking the falling edge at 8.32ns may already be too late to execute as 8ns so it would lock it in as a 12ns pulse. So if we want 8ns, we should be entering 7ns into Lightburn to be sure we always get 8ns. But, even still, they could have baked in tolerance they’re not mentioning.
Boy, this is going to be hard to test, but I think I can come up with a test to see what the threshold is to get from one q-pulse definition to another. But… ok, hell. LB allows only whole ns in the field. I’m making a rough assumption (I could be mistaken) that my 300 follows the 200’s datasheet I do have, which is defined as 2, 4, 6, 9, 13, 20, 30, 45, 60ns… pulses. If I have a test that just shows a change in output, and I see 3ns and 4ns are the same and it actually increments at 5ns, that doesn’t tell me whether 5ns is rounding to the 4ns or 6ns profile.
It would require that FIRST I do 17, 18, 19, 20, 21, 22, 23 ns and see where it changes. Let’s say I see the 17-20 are the same and it changes at 21. I actually DON’T know if 21ns in LB is giving the 20ns or 30ns profile. It could be rounding either way. But the scale is not evenly spaced, and that’s how we decode this. If I keep increasing time, then if the next transition to a different output is at 31 ns, then I know the 21 is rounding to the 20ns profile and 31 is producing the 30ns profile. But if I don’t see a transition until 36, then that means 21ns was rounding UP to 30ns in the first place. 31 would still round to 30ns, as would 41- because there’s no 40ns profile defined. The next profile is at 45ns so seeing the output change at 44-46ns instead of 29-31ns fundamentally exposes whether it’s rounding up or down.
This sounds like obsessively splitting hairs, but no, it’s basic and essential. We just had a cold snap and it’s below freezing in the garage now, too cold to run it to re-test. IIRC, I think I saw the source start dropping out when I put 9ns in and used the “Max Bandwidth” of 4000KHz for the 9ns. Well, it may have clocked that at 9.07ns and rounded that to 13ns, which has a max bw of 3000KHz so a limiter would be tripping. If that’s how rounding works, I need to enter an undefined 8ns to be sure to be recognized as a 9ns profile.
The user also needs to understand this if they’re testing settings. LB also needs to understand this. You shouldn’t bother making a grid of test squares stepping rows as q-pulse from 2ns to 30ns by 2ns, because (let’s use your text) even if 2ns got the 2ns profile, then the 2, 4, 6, and 8 rows are useful, but the 10 is pointless since it’s a repeat of 8ns, 12ns is useful, then 14, 16, 18 are pointless repeats, then 20 is valid, then 4 more pointless rows.
LB needs to be able to be configured so the config has an array of arbitrarily entered q-pulse options. The settings should only let you select one that exists, and if you do a power test grid with q-pulse as an axis, it should only sweep through the defined q-pulse options.
