Yes, I’m aware of Chipp’s version, though I have not tried it. I think I saw some posts on that board
that referred to the later HW 2.72 and 8MB devices, so it may support them, and if it does would also
support V2.81 as I suspect he has kept his code to the documented area, but that’s just a guess.
If you use the Chrome browser, it can be set to translate the Russian pages while browsing the forum…
The MAP mode in my version is basically the same as his video mode as far as I can tell.
I just compiled a speed optimized version for testing, and it gives an overall gain of at least 15%
increase in frame rate for all functions, while a few others gain as much as 25% and some generator
sweep functions as much as 75% at the fastest frequencies/sweep rates. This takes 5 “slots”.
I plan to split this up to 3 slots in the main section, and the remaining 2 some 48KB past the start
of the undocumented area, leaving this space (up to 48KB) for other programs. This should allow a
second program to reside in the 4th slot, and should be compatible with PAWN, which I believe stores
code at the beginning of the undocumented section, as well as does Alterbios for the earlier devices.
With only some 50 or 60KB going past this 48KB point, this should keep well away from the FPGA
section of the V2.81 devices, will need to check all this out.
I also need to implement a chart recorder function for some ovens that need to have their temp
monitored over time, so as time permits will likely be adding this in the future…
Yes i know how to translate it, i even registered and did a couple of posts to see if he is still active and asked about other users about your firmware but it seems both sides are unknown to each other. Either way i haven’t got a reply from CHIPP so i guess he stopped working on it. Haven’t had time to read all the posts though.
I find it really interesting that you keep updating the app and making it better! This version you are talking about i think is the way to go since there is literally no support for v2.81 / 8mb devices anymore, so feel free to use the undocumented area! All Gabonator versions i tested corrupt the FPGA. At least it is easily recoverable and haven’t managed to corrupt the DFU so far. I am a mechanical engineer so i can’t do much to help you, but feel free to ask me to test anything you need on a hw v2.81 (since i know you don’t own one). However please be aware that this is my first oscilloscope and i have not even done any of the hw and sw calibration so far. This is because i need to find an accurate reference (but i guess i can do the hw one with the in-built hw wave generator of the dso).
Wildcat, thanks for the great effort with V4.X, etc. I have a question relative to V4.1. You have files app1.hex, app2.hex and then there are appX.lds files.
If I am to load V4.1 which files do I use? I am assuming you load app1.hex and then load app2.hex. Is that correct?
What are the functions of the .lds files?
Merle
Wildcat 4.2 is a 3-slot program. Since there are only 4 slots available, you can only load Wildcat 4.2 in slots 1-3 (app1.hex) or slots 2-4 (app2.hex).
The LDS files are script files for use with the a complier. You only need to install app1.hex or app2.hex; after which, you’ll have one free slot to load another application.
Dear Wildcat,
first of all let me tell You that Your work is simply amazing!!! You transformed this little monster on a full of features swiss knife.
I would like to suggest You a couple of implementations:
Could You enable a mode where toggles slider modify directly the timebase and voltage divider, I read in the manual that long press of
btn1 and btn4 do this separately (and it works of course) but IMHO have them working simultaneously may improve the user experience, how about?
Is there a way to emulate an old cathode scope by removing/hiding all vertical (or almost vertical) lines drawings?
In some machines we manage at work there is a specific control which can be seen on cathode scopes only.
Some months ago I made a pawn script which generates rs232 and arbitrary binary patterns by reading some txt files from the 8MB memory, the main target was to send a binary stream to a chip (arduino or pic16) which acted as a SIPO in order to have up to 6 digital output channels, if You like to add this feature to function generator I can send to You the script.
thanks again
ciao!
Thanks! Glad to hear the program is being put to good use.
On the 2 sliders: I agree it would be convenient, the only problem is that the right toggle
selects the menu, so if that were dedicated to changing the timebase, how would you get
out of it? Perhaps a certain mode could be engaged (and disengaged) where things would
work this way. Problem is there’s just too few controls. Will give it some thought, maybe
there’s a simple way of doing it.
Not sure what you mean by “vertical line drawings”. If you mean the vertical rise of the
waveform not showing on a CRT type scope if the rise time is fast enough, I guess this could
be emulated, not sure if it would be desirable, though. On a digitally sampled signal, the
program does not know how fast the “step” is, only that it changed from one value to another.
The original author did DIM vertical traces if they were greater than a few steps, giving them a
“thinning effect”. Thought it gave a nice effect so I kept it.
On generating binary patterns, thought about it, at one point actually used the arbitrary
wave generator to do this, using 0’s and 4095’s (limited to 720 clock pulses and of course
the pattern keeps repeating). Would be simple enough to just read a binary stream from a file
and output it with an adjustable bit rate.
In short, there is almost no end to what we can come up with, been trying to implement things
that are relatively simple and don’t use too much code.
At any rate, just finished and will shortly be posting a “speed optimized” version using 3 slots with the rest
of the code in the undocumented area of earlier devices, in such a way as to be compatible with V2.81
hardware, PAWN and the Alterbios plug-in. Version will also add extended time base up to 10 min/div
in the form of a “chart” mode.
Hi Wildcat,
I’m not aware of the priority in the menu, at a first look I would simply say long press btn1 to enter and long press btn4 to leave the “fast control” mode.
Definitely skipping vertical lines isn’t always a good thing, it could be another modality selectable in the ch4 menu.
I guess the simplest way is to skip to draw any dot which has less than N pixels increment in the x axis than the previous
or more than N pixels increment in the y axis according to scanning direction.
You’re right, now I remember the same thing, a drop to 0 or 4095 when passing from the end to the begin of the output wave buffer, this evening I’ll take a look at my pawn code to see how I managed this.
Ciao
Ok here You can download my very raw serialsend pawn script,
copy the .amx, .ini and .232 in the dso memory
use at least 1 time the left slider to read on the screen a blue string (the content of serial.232) after that the waveout port will send out continuously the string, use left slider to modify the baudrate (8n1 fixed at the moment).
Using pawn I wasn’t able to get one shot tx.
Pressing start enable capture on channel C but it still doesn’t work well (I tried to make an rs232 terminal)
btn4 and then btn1 allow to exit from app.
the serial.ini is simple:
VH and VL are 0-4000 the values for low and high output values (0-2.8V)
MAX_CHARS means how many chars can be sent (limited in code to 100)
PAD if 0 the first char of the string is sent immediately after the last, if 1 it waits MAX_CHARS-len(SENT STRING) before resend
THRESHOLD means the min value to get a 1 when capture data
SOURCE232 is the file where the string is read
TESTSTRING is the string sent in case of file reading failure (if this is missing a fixed string is defined in the code
BAUDCUSTOM should be used for advanced timing
TERM not yet used
the function rs232_waveout fills the buffer and update_waveout make it effective
my target is to send the rs232 values to a microcontroller, the values may be directly used to drive a port so 8 outputs at a time.
a spreadsheet could be used to generate strings, baudrate and string length to generate arbitrary multichannel patterns.
As the baudrate can reach 1MHz the resulting freq could be up to 10Khz.
Rewriting rs232_waveout allows to generate a sequence of 0-1 values by reading a txt (6bits per char) or binary file(8bits per char).
in fact every time the buffer is reloaded a positive peak is always present I didn’t found any way to eliminate it except to be sure to have a “1” at the end of the buffer.
All checks has been done with saleae logic analyzer.
Hope You get interest in this
https://app.box.com/s/mqmtdznscf8kkd4wdkyqelan38gr1yh7
Using the shortcut button presses might work. Actually, you would only need one, used as a toggle,
say button 1 long press, then button 4 could still be used normally, or even used for a new function
altogether. Could make BOTH V/div and Time/div menus flash while in this mode to identify it. Would
have to check for any possible interaction issues with other controls, implement a memory of where
the menu was before engaging, etc…
As far as implementing a code generator within the program, as a basic function there should be no
problem. Issues would undoubtedly arise when integrating this so the scope function can simultaneously
function. First of all, I would not run this though a DAC. The risetime is poor, and artifacts such as you have
already noted on ending/starting of buffers abound. I’ve also noted some delay in the DACs to respond
after sitting at 0 level for a while. It just doesn’t make sense to use an analog function to generate digital
data. The data should be output directly through a digital port, allowing much better control, speed and
quality of waveform. Not sure if there is a way to have the processor read a buffer and output the data
in the background, like it does with the DACs, would have to check over the STM32 programming guide
for this, but if not, this could be done with an interrupt, since the timing critical part of an RS232 signal
is within each byte frame, each INT call could do a whole byte, so any INT timing delays would only
affect inter-frame timing, which is not so important for this protocol. INT calls for the sweep gen functions
already implemented at 1000 sweeps/sec are at 10uS interval, and while it does slow the program down,
it’s still fast enough to function adequately. This is where the “speed optimized” versions really help,
nearly doubling frame rate. Calling at this rate would provide 100,000 byte/sec or 1Meg Baud code output.
The sector buffer for file operations holds 4096 bytes and could possibly be used as the read buffer. What I
envision is perhaps 2 new positions for the output generator, “BIN” and “HEX” each reading a file
of the same name in the format of 0’s and 1’s for the BIN file and hex byte values for the HEX file. Baud
rate could be adjusted with the frequency range and fine adjust controls. Depending on how “complete”
the function is to be, you could also set data size in bits, parity and perhaps even polarity as well…
Hi,
Where do I get the newest DSO202 with 8MB and HW vers 2.81?
I have an older DSO203 vers 2.70. I botched it by mounting to a Mac. never fully corrected it. tried briefly with Linux. I have been waiting for a newer version, and then I will be confident to work on correcting the older one, and adding the FFT, and Logic analyzer apps.
If the “fast control” idea isn’t practical, you might want to consider moving the Sample Mode/Rate menu location, between the Run/Hold and CH(A) menus. That way, less toggle switch movement for people not knowing about the shortcuts.
Hi Wildcat,
I made some test with DMA, not so bad to be honest.
from schematics I’ve seen that the waveout opamp is connected to both PB6 which is a PWM output and PA4 which is a DAC output.
I did some test using PA8 (due to my dev board which is inside a DIY RC transmitter):
filled an array with 256 (1 << 8) and 16777216 (1 << 16+8) alternating them as data source.
setted up a DMA channel with in circular mode without Interrupt, the destination address simply as &GPIOA.BSRR and fired up, the picture below is what I got :lol: so , it may generate up to 3.4MHz -> 6.8MBaud!!! I tried various transfer size (from 25 to 1000) but I never noticed any gap or missing pulses in the generated frequency.
Unfortunately my dev board is based on a poor STM32F103C8T6 which don’t have any DAC so my test are limited to digital only.
this is the code (sorry… freepascal) but should be easily understood as the stm32 library is more or less the same
[code]
procedure initDMA;
var
i : word;
begin
for i := 0 to 499 do
begin
data[i*2]:=1 shl 8;
data[i*2+1]:=1 shl 24;
data1[i*2]:=1 shl 8;
data1[i*2+1]:=1 shl 24;
end;
//enable DMA1 clock
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_DMA1, ENABLED);
DMA_DeInit(DMA1_Channel1);
//channel will be used for memory to memory transfer
DMA_InitStructure.DMA_M2M := DMA_M2M_Enable;
//setting normal mode ( circular)
DMA_InitStructure.DMA_Mode := DMA_Mode_Circular;
//medium priority
DMA_InitStructure.DMA_Priority := DMA_Priority_Medium;
//source and destination data size word=32bit
DMA_InitStructure.DMA_PeripheralDataSize := DMA_PeripheralDataSize_Word;
DMA_InitStructure.DMA_MemoryDataSize := DMA_MemoryDataSize_Word;
//automatic memory increment enable. Destination and source
DMA_InitStructure.DMA_MemoryInc := DMA_MemoryInc_Disable;
DMA_InitStructure.DMA_PeripheralInc := DMA_PeripheralInc_Enable;
//Location assigned to peripheral register will be source
DMA_InitStructure.DMA_DIR := DMA_DIR_PeripheralSRC;
//chunk of data to be transfered
DMA_InitStructure.DMA_BufferSize := 26;
//source and destination start addresses
DMA_InitStructure.DMA_PeripheralBaseAddr := @data;
DMA_InitStructure.DMA_MemoryBaseAddr := @PortA.BSRR;
//send values to DMA registers
DMA_Init(DMA1_Channel1, DMA_InitStructure);
//Enable DMA1 Channel transfer
DMA_Cmd(DMA1_Channel1, ENABLED);
end;
[/code]
https://app.box.com/s/foms1y2rt11lkk925qoecvr9kv7p5id4
Ciao
Valerio
That’s the way to do it, now we need to set up a counter to control the speed. I think it would be a useful
addition to the program. As soon as I get some free time, will look into this, and also possibly the menu
mod.
In the meantime, there seems to be some interest in speed optimized versions, so here’s one which loads in
the first 3 slots of the regular memory, leaving the 4th open for other programs, and the rest loaded in
undocumented memory in a way compatible with PAWN, the Alterbios plug-in and hardware V2.81.
Version also adds extended time base from 1 sec/div to 10 mins/div in TrOFF mode as a “chart” function.
Manually reset chart to beginning at left of screen with then . See user guide for more info.
Hi Wildcat,
I only bought my first DSO203 a couple of weeks ago, thinking that I could get a little bit of useful scope with the “portable DDS quality” signal generator, which is what I was really looking for at the time…
When I saw what the original firmware could (not) do in terms of signal generation I had to laugh so hard I just about croaked, but when I was already resigned that now I had that little bit of useful scope with completely and utterly useless signal generation I stumbled across your firmware and now I am hooked. Definitely not my best scope or my best signal generator, but a lovely little bugger and your firmware makes this one hell of an “on the road” tool, so thanks a million for this great job! … :mrgreen:
I just upgraded to V4.2 and wanted to to let you know about a bug I just found. Whenever I set the T2 cursor to a position that is within the region covered by the Meters and then call the Meters with button 3, then cursor T2 is automatically moved from its position to the left border of the Meter window, corrupting any time measurements.
Regards,
Ingmar
I can’t reproduce Ingmar’s problem with his T2 position after a Short-Press of Button 3. T2 seems to work fine on my DSO.
However, I can’t seem to get Chart Mode to work on mine. When I switch to TrOFF mode, the yellow XPOS cursor disappears. When I select a sample rate of yellow 2S or shorter, the XPOS cursor is still not appearing. When I select a sample rate of white 2S or longer, I don’t see the yellow cursor at the top like it states in the manual.
What’s the reasoning for TrOFF being a Sample Mode instead of it being a Trace Mode option?
Revision(W4.2) by Wildcat
AlterBIOS 0.4 OK
Hardware Ver V2.70
SYS Ver 1.52
GCCv1.7W4.1 APP(2.51+SmTech1.8+PMOS69 fixes)
Loaded configuration file
The cursor is supposed to move to the left of the meters when they are engaged. If you have the
“cursor defined meter” option on (an “X” shows at the top in the menu area below Ch 3 when this
is on, hold button 4 down to toggle on/off) then meter readings are restricted to what is enclosed
between the two T cursors, and for time based readings, it requires at least one waveform to be enclosed,
from a + transition to another + transition. Perhaps when the cursor moved, it changed this. Also, if the T2 cursor
is at the very right of the screen (where it actually disappears) whether meters are on or off, as would happen
when engaging the meters with the cursor now shifted up against the right, it will read all the way to the end of
the buffer, whether it’s in large buffer mode or single frame buffer. Perhaps this is altering the readings. Operation
of this mode is detailed in the user guide. Otherwise, can’t think of anything else that could cause something like
this, can you be more specific as to how the time measurements are corrupted?
Regarding the chart mode, the yellow (actually orange) cursor is the trigger cursor. This indicates the
trigger point and it does not show in the TrOFF mode, since it is not triggered in this mode. When
the chart mode is first engaged, the cursor (a short bar at the top) could be anywhere, since it has
not been reset, and in the large buffer mode could be way off screen. Even in single frame buffer
mode, if the window is shifted to the right, the start of the chart could be off screen to the left.
In either case, shift the XPOS all the way to the left, then reset the chart by pressing then
and the position should be visible at the start.
The reason the untriggered mode was used was because it was much easier from a standpoint
of the coding to be implemented this way, and it was thought the mode would be used with
a manual reset anyways. The only difference between the TrOFF mode and a “trace mode” is the lack
of triggering, otherwise the waveforms are exactly the same. Not sure if triggering would be useful in
this case.
Well, “corrupted” is a big word… 
What I meant is this: Any time I place T2 on a position of my waveform that will be covered by the Meter overlay, the T2 cursor is moved away from the position I put it on and is placed on the left border of the Meter window, which will give wrong deltaT readings with respect to my waveform and my intended cursor positions.
i hear you say “well, make sure that both cursors are within the window that remains”, but with the small real estate of the display does it not make more sense to use all there is to display the waveforms and for the Meters to only overlay the right part of the screen, but to not block it? Could you not allow for T2 to move underneath the Meter window and up to the right border?
Mind you, you would then not see where you are going with T2, so “exact” placement of T2 would be difficult except for the help from the updates on deltaV and deltaT, but if you do it the other way around and set cursors first using all of the screen and then call the Meters to show your true deltaV and deltaT, then this makes sense. This could for instance only be made available in Cursor Seelct Meter mode, where it is after all T1 and T2 that define what is reported in the Meter window.
Ok, so the program is working like it was intended, you would just prefer to have the cursor
remain under the meters rather than be shifted over to the visible portion of the screen.
Does it make more sense to leave the cursor behind the meters, I don’t know, perhaps.
The program was the way it is from the original authors, seemed ok, so I didn’t change it.
Changing it around so the cursor stays under the meters, unfortunately would not be as simple
as you would think. For example, in single frame mode, the meters don’t just cover the screen,
the display and data buffers are shifted back so they end at the left of the meters. In order for
the cursor to work properly with all functions, these would have to be extended, which
would then alter the timing of various time bases, functions and delay loops designed
to synchronize everything properly. This would necessitate a major rework of the program…
Thanks for the great explanation of Chart Mode. I think I have it figured out now. I think I was confusing XPOS with the trigger point cursor.
There’s a problem with the XPOS function while in HOLD and TrOFF mode. While in HOLD, XPOS function only works with sample rates of White-2S or longer, but when selecting rates Yellow-2S or shorter, XPOS is non-functional, so you can’t scan the buffer through the display.
I see what Ingmar is concerned with T2. The T2 repositioning is only a minor annoyance since you have the popup meters display the delta value while adjusting T2 without the meters displayed. The T2 repositioning is just an annoyance if you need to readjust T2 again should the waveform change slightly.
It might be better if the meters just behaved as if to just float over the grid; shifting the buffer is unnecessary since you can only see a small part of the buffer with the limited display size, and can view it by scanning through the buffer with XPOS function.
The XPos control is meant to be non functional in the TrOFF mode, as it makes little
sense to scan through a buffer that is not synchronized and displaying basically the same
thing you would see in a single window. For this, use the normal triggered modes.
It was made available with the chart mode part of the TrOFF mode, which is meant to
be manually reset and log long periods of data, so it is desirable in this case.
As far as changing the way the cursors behave in relation to the meters, like I
mentioned before, would take a major program revision.