Well, birthday is late August. This is just something that I really want to have “now”, so I “celebrate” a little early.
I want a scope as well as a signal generator for sure. Then again this is pure hobby, so I have to watch the budget.
I was looking at the Velleman PC USB scopes and generators originally. But the only thing within budget would have been the PCSGU250. I’m a radio amateur too, so I eventually want to look at HF signals, and the 25 Ms/s of that model seemed a little too close for comfort. The overclocked DSO203 can do 144 Ms/s. Going with PC USB, I would need a PCSU1000 + PCGU1000. Awesome combination for sure and if I was single, I would buy that any day over this little gadget. I’m not single and my wife would kill me. Being dead means a serious problem in the “usability” category for me. So that means drool on.
It is a compromise. There are posts from DSO203 users who have solved some of the analog stage bandwidth problems by replacing some of the capacitors. Replacing 0605 sized components on an iPhone sized PCB isn’t for beginners. But I have a working Juma TRX2-A radio, that I assembled from a kit. It doesn’t scare me.
I created another build that changes PR2 to 127 and divides the PWM value by 2 inside the firmware, to adjust from 10 bits to 9 bits resolution. This is probably not what we want in the end, but it works for now.
If using a 30 MHz crystal with an 18F2550 chip, this should make the PWM outputs operate at 23.44 kHz and present 0…100% duty cycle for the K8055D compatibility layer’s 0…255 value range. I still don’t have my scope, so I really don’t know if this is true. My DVM shows close enough values on the DAC outputs though.
This change was committed to the github master branch.
the 30Mhz crystal needs other things in fw to be changed (plldiv, usbdiv,…)
P18F2550.inc - no 30MHz
plldiv can be 6,then PLL will have not 96MHz, but 120MHz; then cpudiv=3 with usb frequency 40Mhz?
will in this case cpu be overclocked, and usb-underclocked?
[quote=“k750”]the 30Mhz crystal needs other things in fw to be changed (plldiv, usbdiv,…)
P18F2550.inc - no 30MHz [/quote]
My mistake. I am using a 20 MHz crystal. There is indeed no configuration for 30 in the data sheet.
The dsPIC30F6014 in my radio runs on 30 MHz. I apparently mixed that up.
Here is a scan of PWM1 of the original PIC16C745 with 6 MHz xtal. Interestingly the Freq is measured at 23.73 kHz which equals a period of 42.16 uS. The duty cycle was set with the original Velleman Demo program (the one with the light bulbs), so that’s just approximately at 50% and of little interest anyway.
And here the same from the PIC18F2550 with 20 MHz xtal. Timer 2 prescaler set to 4, PWMPR2=127. The duty cycle is set to half the 9 bit resolution, or 255, which should ideally result in a 50% duty cycle. It is measured 23.71 kHz, 42.20 uS period and 49.46% duty. Everything is well within the tolerance of all components. The scope has trouble measuring when the duty cycle is below 1% or above 99%.
This all looks good enough to me for now.
Also, I think in the previous build I screwed up the timer 2 prescaler config. I uploaded a new build that has this fixed.
I have a c# aplication polling the inputs with 600ms interval
after about one hour the cpu load is more than 50% and pc is very slow
I used DPC cpu usage and determined the usbport.sys causing this
if I detach the usb cable cpu load drops to normal level
I´m using win 7 64 bits.
do you know what can be? I think 600ms polling period is not so short or it is?
[quote=“diogoc”]I have a c# aplication polling the inputs with 600ms interval
after about one hour the cpu load is more than 50% and pc is very slow
I used DPC cpu usage and determined the usbport.sys causing this
if I detach the usb cable cpu load drops to normal level
I´m using win 7 64 bits.
do you know what can be? I think 600ms polling period is not so short or it is?
regards[/quote]
There is currently a problem with the analog inputs. See this thread for an explanation: viewtopic.php?f=3&t=7976
In short, the fluctuation of the ADC in the lower two bits currently causes the card to send 1,000 HID reports per second.
However, the internal reader thread of my DLL will throw away all the excess HID packets and your 600 ms poll will only consume every 600th HID report. Since you don’t see your application use much CPU, that isn’t your problem.
What I found with a quick Google search is that you are not the only one suffering from that problem and that it seems more related to the USB controller drivers, than what is connected to the USB ports. See if you can find updated drivers for your motherboard or USB expansion cards you may have.
Since you are polling very slow, I could add some calls to the DLL for you that give you access to the cards ability to slow down HID reports. You are only polling every 600ms, so the card could send a report every 100ms only and it would still be 6 times what you need. I will upload another build later today and let you know how to set that configuration. That may provide a workaround in case you can’t fix the problem with drivers.
I think I have found what is causing that
I execute SearchDevices() in the 600ms loop to verify if the board have been disconnected
if I comment that line the cpu load has gone
p.s. I’m not polling analog inputs, only digital inputs
[quote=“diogoc”]I think I have found what is causing that
I execute SearchDevices() in the 600ms loop to verify if the board have been disconnected
if I comment that line the cpu load has gone
p.s. I’m not polling analog inputs, only digital inputs[/quote]
SearchDevices() is going through the USB enumeration for all four possible cards. I don’t know what that enumeration does internally in Windows, but it certainly isn’t so good to constantly do that.
You can use the Connected() function to check if the currently selected card is still connected. It will return TRUE if so, FALSE if it was lost.
Even if you don’t use analog inputs, unless they are set with the on-board ATT1 and ATT2 to zero (full counter-clockwise), they will still cause the HID reports to be hammered in at that 1000/s rate.
I have added a new function “SetHIDReportInterval(int msMin, int msMax)” to the DLL. Using that right after opening the card like
SetHIDReportInterval(100, 100);
will instruct the card to only send 10 reports per second (one every 100ms). For your polling interval, that is more than enough.
I was thinking about making the compatibility layer (my K8055D.DLL) check for an old board on that card address first and if one exists, then to open that instead and talk the original Velleman DLL protocol. That way, one and the same program could access original and modified boards even at the same time.
Would it be acceptable for your program to use my DLL to access original boards? If so, I can spend an hour or two to add legacy support to it.
I’m polling the function Connected() and it is not consuming cpu, so that solve my problem
one thing I noticied is that it not returns true when the board is connected
I have to call Opendevice() for function Connected return true, but is not a big deal
the function is: bool Connected()
without parameters?
that would be nice, but no rush, you can do it when you have time if you like
[quote=“diogoc”]I’m polling the function Connected() and it is not consuming cpu, so that solve my problem
one thing I noticied is that it not returns true when the board is connected
I have to call Opendevice() for function Connected return true, but is not a big deal
the function is: bool Connected()
without parameters?[/quote]
That is how I understand the one in the official Velleman DLL version 4.0.0.2 is working. My entire K8055D.DLL is written from just reading the original Pascal code. Connected() is checking the currently selected card, which is determined by the last call to OpenDevice() or SetCurrentDevice().
Was a very good exercise anyway because it turned up a few bugs in the debounce handling. So the latest version of the K8055D.DLL can now communicate with both types of cards. And it wasn’t that difficult to do. Most of the code existed from the original “emulate-legacy-k8055” branch.
I also changed the firmware main loop a little. The detection of input state changes is now forced to happen in a separate iteration from sending the HID report. This ensures that the main loop executes in under 200 ms, which in turn guarantees that the counters can keep up with a 2 kHz input.
And with that I am calling it release candidate 1 for version 1.0. There will be no more feature changes, only bug fixes and documentation completion.
[quote=“diogoc”]it seems to be working
is necessary copy the 3 dlls for the program working, right?[/quote]
Good to know. I’d like to get a few more positive reports before branching it as 1.0.
Yes, all 3 dlls need to be copied. This K8055D.DLL still references the K8055M.DLL, which in turn references the pthreadGC2.dll. It doesn’t try to link them on demand at runtime, so they are all loaded when the program starts.
But there is no need to ship these DLLs to your customer. Your program will still work with the original Velleman DLL alone using original K8055 boards (as long as you don’t use that SetHIDReportInterval() function). And if your customers want to convert to all this, they can download these DLLs from my website, modify their boards and everything works just the same.
are you actually using this function or not? After reconsidering, I would rather like to remove it from the legacy support layer again in order to keep the k8055d.c as compatible to the original Velleman version as possible.
[quote=“MostlyHarmless”]
are you actually using this function or not? After reconsidering, I would rather like to remove it from the legacy support layer again in order to keep the k8055d.c as compatible to the original Velleman version as possible.
Regards[/quote]
I’m not using this function since it was not necessary for me. So if you think that this function is not very important and you want keep the compatibility, I think you can remove it.
[quote=“diogoc”][quote=“MostlyHarmless”]
are you actually using this function or not? After reconsidering, I would rather like to remove it from the legacy support layer again in order to keep the k8055d.c as compatible to the original Velleman version as possible.
Regards[/quote]
I’m not using this function since it was not necessary for me. So if you think that this function is not very important and you want keep the compatibility, I think you can remove it.
Regards[/quote]
Thank you for quick reply.
It will be removed from the K8055D legacy support. I will instead have it set the report interval internally to 10/10 ms.
It is an important functionality of the k8055m. I am a big fan of event driven applications. If there is nothing to do, don’t do anything. When there is a lot to do, get it done ASAP! A heartbeat every second or so never hurts, even if the information hasn’t changed. But sending a thousand redundant messages per second is a bad design.
When running in legacy compatibility mode, message throttling isn’t an option. One should act as close as possible to the original. In the case of the K8055, that means a fixed HID report interval of 10ms.
I have made a couple substantial changes to the firmware as well as the client code.
[ul][li]All shared libraries are now independent of each other. If your program only needs K8055D.DLL, you only need to copy/install that one. It has the necessary parts of other libraries statically linked in.
[/li]
[li]The Tcl/Tk demo code now uses a proper binding library, that can be installed as a package. All that is needed to run the demos is an installation of ActiveState Tcl/Tk 8.5, then having the demo.tcl or demo_digital_out.tcl together with tclk8055m.dll in one directory.
[/li]
[li]The above obsoletes the k8055control.exe command line utility. It was removed to avoid keeping slowly rotting code around.
[/li]
[li]The Standard Servo digital output mode is fully implemented. I will post another thread with a more detailed explanation. This functionality is entirely interrupt driven. It required to move interrupt priorities around, but all that is transparent.[/li][/ul]
All of those changes are available in the 2012-07-02 developers snapshot or via the github repository.
