Seairth,
It was not a personal attack, just stating the facts of what anyone can see here in the P2 forums. Phil constantly posting for Chip to stop doing what he wants to do.
I like Phil, and he has contributed a great deal over the years to Parallax and the forums, but he just seems to be nothing but negative in this P2 sub forum. I don't understand why he does it over and over. It's not healthy to always be so negative.
I want the P2 to get done also, but I also want Chip to make what he wants and be happy/satisfied with it. That will be the P2 chip that we all love to use. I know Chip would regret not making the changes he felt he could in the time he feels is available.
Also, I am not one that subscribes to the idea that all opinions are welcome, sorry, but constant negatives are not welcome. It's different from just having a differing opinion about how and what get done, it's about being negative towards the whole process. Phil has said several times he'd rather have Chip go off alone, not listening to any of us, and make the P2. He views this whole open process as a bad thing that should not have been done.
Roy, Phil's concerns relate to Parallax's business and future. He wants to see the company and employees succeed and is looking at the P2 from the perspective of value-engineering and diminishing returns. Parallax also has business with Phil, and his success depends on ours to some extent.
I'm sure Chip will be happy with the outcome no matter what people ask him to do. Nobody has ever forced Chip successfully to do anything other than what he wants to do. It has not happened in our history.
I think Phil is just expressing the frustration that many of us have had waiting for the P2 over the past several years. I have made comments similar to Phil's many times in the past. At this point I don't think Chip is in the critical path as far as the schedule is concerned. The P2 development board should be in the hands of dozens of users within a couple of weeks. I'm looking forward to trying out lots of things on the P2. However, I would be disappointed if I don't get the board by Christmas.
Phil, maybe you are concerned that Chip isn't focusing on Spin for the P2. I would suggest using Eric's fastspin compiler. It has some of the new features that have been proposed for Spin2, and it should run pretty fast on the P2.
And, no chip has ever been designed this way before, because of the secretive nature of the semiconductor industry.
Heater might raise the RISC-V about now. Although, that isn't a collective effort for one implementation - It's just a collection for pillaging. Like BSD was before Linux brought GPL into the mix.
Please explain more. I want to understand.
By "a collection for pillaging" I mean same as what we're doing with Sinc. We've discovered it's a useful addition for the Propeller to have. So we cherry pick just what we want from a much larger mathematical heritage. One function from a bigger library.
BSD was functional in the 1980's but no-one treated it as a finished product. It was always just picked over for useful methods and tools to add to other products.
I really do want the P2 to succeed -- but not at the expense of Parallax's other business, which seems to be where things are headed with these interminable delays and sidetracks. There's a cost to be reckoned with, and I don't think Chip is cognizant of that. Family-wage jobs and Parallax's financial survival are at stake here, while Chip fiddles away at one self-indulgent diversion after another. So even though I don't see the P2 in any future implementations of my own, its success is vitally important to Parallax's continued viability with the P1 and their other products, and hence to me.
So I shall continue to hammer on the theme that I've established from the beginning: that the P2 should be a result of Chip's singular vision -- as was the P1 -- and that it needs to get FINISHED, even if that entails compromise. Remember, "Perfect is the enemy of good enough." And after nearly 13 years in development, good enough will have to suffice, or there never will be a P2; and the very survival of Parallax -- the company we all love -- will be challenged as never before.
A 4 channel "scope" does sound pretty cool and even if the analog bandwidth is limited to several MHz I can imagine it could come in very handy for audio and for other signal processing.
Yes, and of course there is the 250Mhz streamer in there for the Logic Analyzer capture of digital signals too.
Also in there I think, is a threshold adjustable by DAC, but I've not seen the speed spec testing results on that yet, or the range ?
Yes, it turns out this is a separate DAC, slower and presumably higher impedance than the others.
I missed/forgot about it when testing the other DACs, so we'll come back to it. There is a way to expose the threshold voltage through adjacent pin B that we'll take advantage of, then run the same GIO/ramp up/VIO/ramp down/GIO sequence that we did for the other DACs
Evan, do you have a simulated bitstream that you could input into Sinc3? If so, could you try acc1/2/3=30/27/24-bit?
I've got a basic auto-generating ramp setup from earlier work.
First attempt:
- Reset every 256 clocks, with 4 sub-samples, is matching the old output perfectly.
- Pure rolling window has some sort of roll-over problem going negative ... at 8th sample - clock 2000ish.
Phil,
The P2 is not and has never been Chip's single vision. He has collaborated with others continuously over the 13 years. It's the path that Chip & Ken chose for the P2 to be open in its development. You disagree with that, you have said so many times. I'm sorry, but I don't think it's going to change.
I get all the other stuff, and I worry about them also, but I don't tell Chip and Ken how to run their development. They wouldn't and shouldn't listen to me on that. I also know Ken and his team have made changes and are succeeding and I believe they will continue to do so. The P2 is closer to done than it's ever been, and they are on the path to its completion WITH the collaboration and Chip working on what he feels is important.
I'm just tired of hearing "stop doing what you want to be doing and feel is important, and instead do what I say" coming from you for the last decade.
Ken,
I share the worry about Parallax with Phil, but I trust that you have been running things and keeping things going.
Honestly, I am more concerned about the things impacting your business besides the P2, like the tariff Smile raising costs, and the impending economic disasters we all face in the near future (from many fronts).
A 4 channel "scope" does sound pretty cool and even if the analog bandwidth is limited to several MHz I can imagine it could come in very handy for audio and for other signal processing.
Yes, and of course there is the 250Mhz streamer in there for the Logic Analyzer capture of digital signals too.
Also in there I think, is a threshold adjustable by DAC, but I've not seen the speed spec testing results on that yet, or the range ?
Yes, it turns out this is a separate DAC, slower and presumably higher impedance than the others.
I missed/forgot about it when testing the other DACs, so we'll come back to it. There is a way to expose the threshold voltage through adjacent pin B that we'll take advantage of, then run the same GIO/ramp up/VIO/ramp down/GIO sequence that we did for the other DACs
Those tests would all be useful additions to the DAC test portfolio, but I was meaning more the speed of the digital pathway, and the common mode range of the comparator used with the DAC
I doubt that will manage to follow a 100+MHz signal ?
You could test the narrow pulse operation, by generate of a PWM on one pin, and Threshold-path capture on another, and vary duty down to 1 sysclk.
A capture of 2 pin paths, one straight std digital, and one via threshold-compare could also show the propagation delays ?
I've had my say. Feedback from you and other forumistas is always welcome. We share the same objectives -- the ultimate success of Parallax -- but perhaps not the same methods. And I respect that.
Evan, do you have a simulated bitstream that you could input into Sinc3? If so, could you try acc1/2/3=30/27/24-bit?
I've got a basic auto-generating ramp setup from earlier work.
First attempt:
- Reset every 256 clocks, with 4 sub-samples, is matching the old output perfectly.
- Pure rolling window has some sort of roll-over problem going negative ... at 8th sample - clock 2000ish.
If you restore the pruned bits, does that roll-over problem go away ? Is there any pruned-count solution, or do all accs need to be 30 bits ?
My concern is also for Parallax, not my own interests.
The current P2 silicon (alpha if you like) is here. It works but has some minor flaws.
What concerns me is that the digression from just fixing what needs to be fixed is being derailed by some keen to see the chip go in different directions, and add in many new features. They are not fixes nor minor tweeks!
There is a limited time frame here. And that time is not being spent on the things that matter!
If it were not for the signed bug, and the power issue, I would be saying keep the P2 as-is.
Everyone is entitled to state their position without fear. Whether it's taken is for Chip & Ken to decide.
Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.
Cluso, I am of the same opinion that Parallax should just be fixing bugs in the P2, and not adding other features. I I
I'm concerned that additional bugs will be introduced, and Parallax will have to do a third round of silicon to fix the new bugs. Time will tell.
Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.
Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.
Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.
Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.
Pruning the differentiators/combs is a waste of time, literally. I wonder if we could prune acc2 and acc3 a bit more. The basic concept is that the cumulative errors from pruning should be no more than the truncation error without pruning. If we don't prune the combs, we might be able to have bigger errors and hence bigger pruning for the acc's.
I think acc1 should be 30+1 bits wide, but we can prune it by 1 bit so 30-bit is OK.
Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.
Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.
Cluso, I am of the same opinion that Parallax should just be fixing bugs in the P2, and not adding other features. I I
I'm concerned that additional bugs will be introduced, and Parallax will have to do a third round of silicon to fix the new bugs. Time will tell.
And can Parallax afford a third round of silicon???
Got it! Both variants are doing exactly same ramp. Point for point.
I've taken on board Tony's suggestion about moving everything up to the top of the native variables too, in this case C datatype uint32_t. So, for each bit in the bitstream, I'm adding four to Acc1 and masking off the bottom two lsbits instead of adding one and masking off the two msbits. Same story for the remaining register emulation.
So that probably means I had a register alignment problem before. As he said, the msbit is what lines up down the stages.
Got it! Both variants are doing exactly same ramp. Point for point.
I've taken on board Tony's suggestion about moving everything up to the top of the native variables too, in this case C datatype uint32_t. So, for each bit in the bitstream, I'm adding four to Acc1 and masking off the bottom two lsbits instead of adding one and masking off the two msbits. Same story for the remaining register emulation.
So that probably means I had a register alignment problem before. As he said, the msbit is what lines up down the stages.
Will all this work for non-power-of-2 sample counts?
It has lost a little resolution. The slow starting ramp up of that 50000 clocks now has a flat three samples then a one sample over reaction before settling.
It has lost a little resolution. The slow starting ramp up of that 50000 clocks now has a flat three samples then a one sample over reaction before settling.
I think you're still pruning the diff's. If so, please don't as there is no need.
How many errors in the two 50000 cycles? Just the LSB? Try rounding.
It's not my idea. I've been doing some reading and this is called Integrate and Dump. It could be used elsewhere in the smart pins, probably. In the differentiator diff1 stores the previous value of acc3, but if acc3 is reset after being read then diff1 is redundant.
I like this idea. In typical operation we would just be calculating the difference anyway. This saves an instruction or two.
The proposed Tukey window is better than a sinc3 length 8, mostly because the inpulse response is longer. Comparing it to a length 16 sinc3 it's mixed.
Top line=Tukey full scale = 1023 , truncate 2 lsb (/4)
Middle line=Sinc^38 full scale =512, truncate 1 lsb (/2)
Bottom line=Sinc^316 full scale = 4096, truncate 4 lsb (/16)
Mean Value (channels 1-8 gio) , (channels 1-8 vio)
45.36748.50644.40745.59643.59643.39448.90646.799212.372214.971214.590214.560211.250212.677215.867215.05845.46848.79644.69445.73943.67243.45249.24747.111212.613215.312214.924214.897211.585212.879216.276215.40645.23648.33944.60545.46843.48543.26548.92946.685212.550215.054214.720214.702211.387212.827215.931215.120
Standard Deviation (channels 1-8 gio) , (channels 1-8 vio)
0.551940.513240.559210.502850.532370.618390.352900.474190.728350.405260.527420.530020.493770.546100.404210.312771.569011.880771.744511.511021.778941.718221.889831.510531.353281.562011.648101.657151.732801.359941.068981.494030.436810.515410.508860.505280.569740.691420.707890.493650.711130.536710.472270.502490.537670.510450.388890.42351
For the Tukey, the max could be anywhere from 1020-1023. It doesn't have to be 1023.
The cutoff frequency seems just a little low for analog video. Although I wonder what the response is on the analog part of the chip.
Will all this work for non-power-of-2 sample counts?
No problem at all. In my source there, the "chunklen" is the clocks per sample. EDIT: Amusingly it should even work for sub-word bit positions in the bitstream. Not something I explicitly tried to make work.
Comments
It was not a personal attack, just stating the facts of what anyone can see here in the P2 forums. Phil constantly posting for Chip to stop doing what he wants to do.
I like Phil, and he has contributed a great deal over the years to Parallax and the forums, but he just seems to be nothing but negative in this P2 sub forum. I don't understand why he does it over and over. It's not healthy to always be so negative.
I want the P2 to get done also, but I also want Chip to make what he wants and be happy/satisfied with it. That will be the P2 chip that we all love to use. I know Chip would regret not making the changes he felt he could in the time he feels is available.
Also, I am not one that subscribes to the idea that all opinions are welcome, sorry, but constant negatives are not welcome. It's different from just having a differing opinion about how and what get done, it's about being negative towards the whole process. Phil has said several times he'd rather have Chip go off alone, not listening to any of us, and make the P2. He views this whole open process as a bad thing that should not have been done.
I'm sure Chip will be happy with the outcome no matter what people ask him to do. Nobody has ever forced Chip successfully to do anything other than what he wants to do. It has not happened in our history.
Ken Gracey
I think Phil is just expressing the frustration that many of us have had waiting for the P2 over the past several years. I have made comments similar to Phil's many times in the past. At this point I don't think Chip is in the critical path as far as the schedule is concerned. The P2 development board should be in the hands of dozens of users within a couple of weeks. I'm looking forward to trying out lots of things on the P2. However, I would be disappointed if I don't get the board by Christmas.
Phil, maybe you are concerned that Chip isn't focusing on Spin for the P2. I would suggest using Eric's fastspin compiler. It has some of the new features that have been proposed for Spin2, and it should run pretty fast on the P2.
By "a collection for pillaging" I mean same as what we're doing with Sinc. We've discovered it's a useful addition for the Propeller to have. So we cherry pick just what we want from a much larger mathematical heritage. One function from a bigger library.
BSD was functional in the 1980's but no-one treated it as a finished product. It was always just picked over for useful methods and tools to add to other products.
I really do want the P2 to succeed -- but not at the expense of Parallax's other business, which seems to be where things are headed with these interminable delays and sidetracks. There's a cost to be reckoned with, and I don't think Chip is cognizant of that. Family-wage jobs and Parallax's financial survival are at stake here, while Chip fiddles away at one self-indulgent diversion after another. So even though I don't see the P2 in any future implementations of my own, its success is vitally important to Parallax's continued viability with the P1 and their other products, and hence to me.
So I shall continue to hammer on the theme that I've established from the beginning: that the P2 should be a result of Chip's singular vision -- as was the P1 -- and that it needs to get FINISHED, even if that entails compromise. Remember, "Perfect is the enemy of good enough." And after nearly 13 years in development, good enough will have to suffice, or there never will be a P2; and the very survival of Parallax -- the company we all love -- will be challenged as never before.
-Phil
Yes, it turns out this is a separate DAC, slower and presumably higher impedance than the others.
I missed/forgot about it when testing the other DACs, so we'll come back to it. There is a way to expose the threshold voltage through adjacent pin B that we'll take advantage of, then run the same GIO/ramp up/VIO/ramp down/GIO sequence that we did for the other DACs
I've got a basic auto-generating ramp setup from earlier work.
First attempt:
- Reset every 256 clocks, with 4 sub-samples, is matching the old output perfectly.
- Pure rolling window has some sort of roll-over problem going negative ... at 8th sample - clock 2000ish.
The P2 is not and has never been Chip's single vision. He has collaborated with others continuously over the 13 years. It's the path that Chip & Ken chose for the P2 to be open in its development. You disagree with that, you have said so many times. I'm sorry, but I don't think it's going to change.
I get all the other stuff, and I worry about them also, but I don't tell Chip and Ken how to run their development. They wouldn't and shouldn't listen to me on that. I also know Ken and his team have made changes and are succeeding and I believe they will continue to do so. The P2 is closer to done than it's ever been, and they are on the path to its completion WITH the collaboration and Chip working on what he feels is important.
I'm just tired of hearing "stop doing what you want to be doing and feel is important, and instead do what I say" coming from you for the last decade.
I share the worry about Parallax with Phil, but I trust that you have been running things and keeping things going.
Honestly, I am more concerned about the things impacting your business besides the P2, like the tariff Smile raising costs, and the impending economic disasters we all face in the near future (from many fronts).
Those tests would all be useful additions to the DAC test portfolio, but I was meaning more the speed of the digital pathway, and the common mode range of the comparator used with the DAC
I doubt that will manage to follow a 100+MHz signal ?
You could test the narrow pulse operation, by generate of a PWM on one pin, and Threshold-path capture on another, and vary duty down to 1 sysclk.
A capture of 2 pin paths, one straight std digital, and one via threshold-compare could also show the propagation delays ?
I've had my say. Feedback from you and other forumistas is always welcome. We share the same objectives -- the ultimate success of Parallax -- but perhaps not the same methods. And I respect that.
-Phil
If you restore the pruned bits, does that roll-over problem go away ? Is there any pruned-count solution, or do all accs need to be 30 bits ?
The current P2 silicon (alpha if you like) is here. It works but has some minor flaws.
What concerns me is that the digression from just fixing what needs to be fixed is being derailed by some keen to see the chip go in different directions, and add in many new features. They are not fixes nor minor tweeks!
There is a limited time frame here. And that time is not being spent on the things that matter!
If it were not for the signed bug, and the power issue, I would be saying keep the P2 as-is.
Everyone is entitled to state their position without fear. Whether it's taken is for Chip & Ken to decide.
EDIT: And the code for each variant:
case 23:// Sinc3 algorithm, with pruning if( reset & 1 ) acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0; indexSV = bitindex + chunklen; do { acc3 = (acc3 + acc2) & ACC3MASK; acc2 = (acc2 + acc1) & ACC2MASK; bits = bitstream[bitindex >> SIZEEXP]; if( (bits >> (bitindex & SIZEMASK)) & 1 ) // C bitfield extraction { acc1 = (acc1 + 1) & ACC1MASK; } bitindex++; } while( bitindex < indexSV ); reading = acc3 - diff1 - diff2 - diff3; diff3 = (acc3 - diff1 - diff2) & DIF3MASK; diff2 = (acc3 - diff1) & DIF2MASK; diff1 = acc3 & DIF1MASK; break; case 33:// Sinc3 algorithm, with pruning, alternate truncation if( reset & 1 ) acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0; indexSV = bitindex + chunklen; do { acc3 = (acc3 + acc2) & ACC3MASK; acc2 = (acc2 + acc1) & ACC2MASK; bits = bitstream[bitindex >> SIZEEXP]; if( (bits >> (bitindex & SIZEMASK)) & 1 ) // C bitfield extraction { acc1 = (acc1 + 1) & ACC1MASK; } bitindex++; } while( bitindex < indexSV ); reading = acc3 - diff1 - diff2 - diff3; diff3 = (acc3 - diff1 - diff2) & ACC3MASK; diff2 = (acc3 - diff1) & ACC3MASK; diff1 = acc3 & ACC3MASK; break;EDIT2: The truncation masking:
// register masking for pruning #define ACC1SIZE 30 #define ACC1MASK ((1 << ACC1SIZE ) - 1) #define ACC2MASK ((1 << (ACC1SIZE - 3)) - 1) #define ACC3MASK ((1 << (ACC1SIZE - 6)) - 1) #define DIF1MASK ((1 << (ACC1SIZE - 7)) - 1) #define DIF2MASK ((1 << (ACC1SIZE - 8)) - 1) #define DIF3MASK ((1 << (ACC1SIZE - 9)) - 1)Evan, I think you're pruning the MSB's, which is wrong. The LSB's are pruned. Also you don't actually need DIFxMASK as pruning the differentiators saves no logic.
I'm concerned that additional bugs will be introduced, and Parallax will have to do a third round of silicon to fix the new bugs. Time will tell.
Ah, I shouldn't have called that pruning or truncating. It's defining the register size to emulate.
Right, but it's working? If so, that's excellent.
If you're interested in precise pruning, take a look at
https://www.so-logic.net/documents/trainings/03_so_implementation_of_filters.pdf
and search for: Pruning LSBs
Pruning the differentiators/combs is a waste of time, literally. I wonder if we could prune acc2 and acc3 a bit more. The basic concept is that the cumulative errors from pruning should be no more than the truncation error without pruning. If we don't prune the combs, we might be able to have bigger errors and hence bigger pruning for the acc's.
I think acc1 should be 30+1 bits wide, but we can prune it by 1 bit so 30-bit is OK.
This pruning is slightly lossy, right?
And can Parallax afford a third round of silicon???
I've taken on board Tony's suggestion about moving everything up to the top of the native variables too, in this case C datatype uint32_t. So, for each bit in the bitstream, I'm adding four to Acc1 and masking off the bottom two lsbits instead of adding one and masking off the two msbits. Same story for the remaining register emulation.
So that probably means I had a register alignment problem before. As he said, the msbit is what lines up down the stages.
EDIT: Here's latest source code:
case 23:// Sinc3 algorithm, with pruning if( reset & 1 ) acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0; indexSV = bitindex + chunklen; do { acc3 = (acc3 + acc2) & ACC3MASK; acc2 = (acc2 + acc1) & ACC2MASK; bits = bitstream[bitindex >> SIZEEXP]; if( (bits >> (bitindex & SIZEMASK)) & 1 ) // C bitfield extraction { acc1 = (acc1 + (1 << (WORDSIZE - ACC1SIZE))) & ACC1MASK; } bitindex++; } while( bitindex < indexSV ); reading = acc3 - diff1 - diff2 - diff3; diff3 = (acc3 - diff1 - diff2) & DIF3MASK; diff2 = (acc3 - diff1) & DIF2MASK; diff1 = acc3 & DIF1MASK; break;// word size exponent, taper length exponent #define SIZEEXP 5 #define WORDSIZE (1 << SIZEEXP) #define SIZEMASK (WORDSIZE - 1) // register emulation masking #define ACC1SIZE 30 #define ACC1MASK (~((1 << (WORDSIZE - ACC1SIZE)) - 1)) #define ACC2MASK (~((1 << (WORDSIZE + 3 - ACC1SIZE)) - 1)) #define ACC3MASK (~((1 << (WORDSIZE + 6 - ACC1SIZE)) - 1)) #define DIF1MASK (~((1 << (WORDSIZE + 7 - ACC1SIZE)) - 1)) #define DIF2MASK (~((1 << (WORDSIZE + 8 - ACC1SIZE)) - 1)) #define DIF3MASK (~((1 << (WORDSIZE + 9 - ACC1SIZE)) - 1))Will all this work for non-power-of-2 sample counts?
So both pruning variants are exactly the same as no pruning?
It has lost a little resolution. The slow starting ramp up of that 50000 clocks now has a flat three samples then a one sample over reaction before settling.
I think you're still pruning the diff's. If so, please don't as there is no need.
How many errors in the two 50000 cycles? Just the LSB? Try rounding.
Done, no difference at all that I could see.
Here's a graph with all three:
- Yellow is my older method using all 32-bit
- Blue is the tightest with diff masking
- Red has no diff masking
The proposed Tukey window is better than a sinc3 length 8, mostly because the inpulse response is longer. Comparing it to a length 16 sinc3 it's mixed.
Top line=Tukey full scale = 1023 , truncate 2 lsb (/4) Middle line=Sinc^3 8 full scale =512, truncate 1 lsb (/2) Bottom line=Sinc^3 16 full scale = 4096, truncate 4 lsb (/16) Mean Value (channels 1-8 gio) , (channels 1-8 vio) 45.367 48.506 44.407 45.596 43.596 43.394 48.906 46.799 212.372 214.971 214.590 214.560 211.250 212.677 215.867 215.058 45.468 48.796 44.694 45.739 43.672 43.452 49.247 47.111 212.613 215.312 214.924 214.897 211.585 212.879 216.276 215.406 45.236 48.339 44.605 45.468 43.485 43.265 48.929 46.685 212.550 215.054 214.720 214.702 211.387 212.827 215.931 215.120 Standard Deviation (channels 1-8 gio) , (channels 1-8 vio) 0.55194 0.51324 0.55921 0.50285 0.53237 0.61839 0.35290 0.47419 0.72835 0.40526 0.52742 0.53002 0.49377 0.54610 0.40421 0.31277 1.56901 1.88077 1.74451 1.51102 1.77894 1.71822 1.88983 1.51053 1.35328 1.56201 1.64810 1.65715 1.73280 1.35994 1.06898 1.49403 0.43681 0.51541 0.50886 0.50528 0.56974 0.69142 0.70789 0.49365 0.71113 0.53671 0.47227 0.50249 0.53767 0.51045 0.38889 0.42351For the Tukey, the max could be anywhere from 1020-1023. It doesn't have to be 1023.
The cutoff frequency seems just a little low for analog video. Although I wonder what the response is on the analog part of the chip.
case 33:// Sinc3 algorithm, with pruning, with 32-bit software diff'ing if( reset & 1 ) acc1 = acc2 = acc3 = diff1 = diff2 = diff3 = 0; indexSV = bitindex + chunklen; do { acc3 = (acc3 + acc2) & ACC3MASK; acc2 = (acc2 + acc1) & ACC2MASK; bits = bitstream[bitindex >> SIZEEXP]; if( (bits >> (bitindex & SIZEMASK)) & 1 ) // C bitfield extraction { acc1 = (acc1 + (1 << (WORDSIZE - ACC1SIZE))) & ACC1MASK; } bitindex++; } while( bitindex < indexSV ); reading = (acc3 - diff1 - diff2 - diff3) >> (WORDSIZE - ACC1SIZE); diff3 = acc3 - diff1 - diff2; diff2 = acc3 - diff1; diff1 = acc3; break;No problem at all. In my source there, the "chunklen" is the clocks per sample. EDIT: Amusingly it should even work for sub-word bit positions in the bitstream. Not something I explicitly tried to make work.