Just made the base board and got a problem. The regulator works good until I turn the VPPU on. After that the VPP and VPPU could not be set higher than 10 V. Checked all around Q1 and Q3, also checked the VPPU network. All is OK. When the slider is at 9 V the duty cycle is around 20%. When I move the slider to 11 V the duty cycle jumps to 80%. Why does this happen? Collector current of Q1 and Q3 is very small (smaller than a milliampere).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-04-28
There is an issue with opgui on linux (ubuntu 16.04). It halts while reading or writing a device (I'm trying a 24lc64 i2c memory chip). As a solution I run the opgui with strace, and all is ok then. There is no such an issue on windows machine - all goes ok. Looks like it has to slow down under linux. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-05-04
Ubuntu 16.04 x64, Intel Dual-Core E5400 @ 2.70GHz, 8 GB RAM. Here is how it's look like. The percentage is everytime different. The log is empty. Maybe it lacks a bypass capacitor on the VDD. Will try and reply soon. Thank you for assistance!
No, that's not a typo.
If you do that every packet takes at least 40ms, and you will likely have a very slow data transfer rate.
But you're in the right function; as a temporary solution insert a longer delay here:
3303: usleep(x>MinDly?x:MinDly);
You can experiment with the value a little bit, I would say a few ms:
usleep(3000);
But it depends from your system.
I am working on a better solution that requires no additional delays.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-05-05
The PacketIO function usually called with a little delay in the argument. 8 or 10. So the first execution of delay-=TIMEOUT-10 gives a negative number because the TIMEOUT defined with value of 50.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-05-05
Maybe the right way is to calculate the delays in runtime? Measure the speed of system and interface by sending the test packets and adjust.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
delay is set to 0 if <0
In general there is an expected execution time that depends from the commands issued in the packet, and this is passed to this function.
However, for many other reasons, the real required time could be longer or slightly shorter, so a timeout is used; an additional delay is needed when the expected time is longer than the timeout.
This is the right way to proceed, non need for fancy algorithms; it works perfectly under Windows.
In linux I am using a mix of IOCTL and file IO calls, which is not ideal.
I am working on a full file IO version with "select" wait call.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just made the base board and got a problem. The regulator works good until I turn the VPPU on. After that the VPP and VPPU could not be set higher than 10 V. Checked all around Q1 and Q3, also checked the VPPU network. All is OK. When the slider is at 9 V the duty cycle is around 20%. When I move the slider to 11 V the duty cycle jumps to 80%. Why does this happen? Collector current of Q1 and Q3 is very small (smaller than a milliampere).
It sounds like some parasitic load.
Duty cycle is limited to 80%.
I've solved the problem. Had to reduce the R10 down to 1k. Seems my BC547 wasn't close fast enough, so it needed a bit more current in the base.
Also a good explanation, and solution.
There is an issue with opgui on linux (ubuntu 16.04). It halts while reading or writing a device (I'm trying a 24lc64 i2c memory chip). As a solution I run the opgui with strace, and all is ok then. There is no such an issue on windows machine - all goes ok. Looks like it has to slow down under linux. :)
Strange, what system is that?
OS, cpu
Ubuntu 16.04 x64, Intel Dual-Core E5400 @ 2.70GHz, 8 GB RAM. Here is how it's look like. The percentage is everytime different. The log is empty. Maybe it lacks a bypass capacitor on the VDD. Will try and reply soon. Thank you for assistance!
Tried to add more capacitors but with no success. That's very strange because if the app launched via strace it works fine.
It's me again. I've just found the bug. In the opgui.c there is a function named PacketIO. And there are two lines like this:
That -= looks very strange, so I replaced it with = in both the lines:
Now it works! =)
Here is the patch for opgui.
No, that's not a typo.
If you do that every packet takes at least 40ms, and you will likely have a very slow data transfer rate.
But you're in the right function; as a temporary solution insert a longer delay here:
3303: usleep(x>MinDly?x:MinDly);
You can experiment with the value a little bit, I would say a few ms:
usleep(3000);
But it depends from your system.
I am working on a better solution that requires no additional delays.
The PacketIO function usually called with a little delay in the argument. 8 or 10. So the first execution of
delay-=TIMEOUT-10gives a negative number because the TIMEOUT defined with value of 50.Maybe the right way is to calculate the delays in runtime? Measure the speed of system and interface by sending the test packets and adjust.
delay is set to 0 if <0
In general there is an expected execution time that depends from the commands issued in the packet, and this is passed to this function.
However, for many other reasons, the real required time could be longer or slightly shorter, so a timeout is used; an additional delay is needed when the expected time is longer than the timeout.
This is the right way to proceed, non need for fancy algorithms; it works perfectly under Windows.
In linux I am using a mix of IOCTL and file IO calls, which is not ideal.
I am working on a full file IO version with "select" wait call.