Alternative dso firmware [Application Software Design Entry]

Congratulations Gabriel. You truly deserve the honour.

Congrats Gabriel !!

Looks like you’re gonna have a metal case DSO Quad after all :wink:

Hallo gabonator1,



just one question: Did you plan to finish the Oscilloscope/Calibration Modul for your DS203 customized firmware?



Greetings from Germany

Thomas

Hello gys,



thank you for your support in the competition! I am very happy to be the winner, but I am also a little disappointed by the fact JPA didn’t win anything since he did a lot of very important work including fixing the BIOS FAT functions and developing first customized FPGA image…



Hallo Thomas, naturlich ich mochte das Firmware besser machen, vielleicht nicht dieses Monat, weil ich habe zu viel zu tun fur die Schule, und was fur funktionen fehlt dir in dem Oscilloscope Modul?

And regarding the calibration - I think there are not a lot things to improve - current hardware version of DSO is simply not designed to be a precise measurement device.



Currently I am working on my disertation thesis and also I am working on one publication I would like to finish in few weeks - it is about measuring the gamma radiation, I have used the DSO as a impulse counter for GM tube, it sends the calculated gamma dose rate value through bluetooth to PC, a GPS module is also attached to PC to build the radiation map.



Measurement from yesterdays trip around my city can be seen here:

http://pub.valky.eu/geiger/

Hello gabonator1,


Regarding the completion degree of your firmware, maybe there is a confusion because you write



[size=85]Todo list:

finish oscilloscope module - 92% done

calibration - 80% done

fft view - 80% done

signal generator - 90% done

connection with android tablet/phone - 90% done

optimize ROM usage (many bitmaps are stored as 8bits per pixel) - 0%

[/size]

… but to be honest, I didn’t notice anything not working…



There is a function which I would love: the ability to display alle 4096 samples at once by default (i.e. a complete sweep) and to be able to zoom in (a factor 16 = 4096/256 shoud be possible). Of course, this would not work for the shortest time bases. Maybe this is what is called oversampling. Or is it already implemented and I didn’t find it?



Anyways, I congratulate for your fantastic work, thank you!

Patrick

Patrick, it’s already there, User modules -> Zoom, it allows you to see whole 4096 sample buffer on single screen as well as zooming in to see few samples on screen.



Thank you Gabriel, this is great.



I have played with this feature yesterday, but it is not very useful for me because:

  • I couldn’t stop sampling (as “zoom” it is not integrated in the oscilloscope, the usual commands do not apply)
  • triggering was not stable (the wave is stable in the oscilloscope, but not in the “zoom” mode)



    … but your Alternative dso firmware is something fantastic and I don’t intend to use anything else in the future - with or without zoom!



    Another question: is there something like an user documentation? The firmware is very user friendly but some informations about specific functions or the general philosophy would be helpful (e.g. the fact that the generator seems to be in a separate software block, but in reality it still works while the oscilloscope is running, or how to use the masks, the cursors, the PID controller…). Some informations about the compatibility with other applications (like jpa’s Pawn interpreter and alterbios) would be helpful too.



    Thanks+Regards

    Patrick

Patrick, I know that there are some issues… And the for now no documentation is available… But I have also good news, today I have finished the software (bitbanged) I2C interface, it uses the USART TX/RX pins for communication



The GPIO user application automatically identifies the attached device and display some report including decoded variables from sensors, so far these devices are supported:



DS1820 - oneWire temperature sensor

DHT11 - humidity & temperature sensor

BMP085 - I2C barometric sensor (temperature & pressure)

Dear GABONATOR,

Dear All,



Sorry to disturb you but I’ve read the whole post and I always can not download the nice APP_G251.hex to my DSO Quad.

While transfering the hex file, the system stops at 1/2 or 2/3 of the full transfert and wrote not enough memory.

I did a lot of various upgrade with hex files in the past, but can not with this one.



My spécifications are:

Alterbios 0.3

HW 2.60

Sys 1.52

App 2.53



I’ve checked to well download a text HEX file.

APP_G251.hex is 491Kb, starts with

:020000040800F2

:10C000000000012065510508794F05087B4F0508A0

:10C010007D4F05087F4F0508814F0508000000008F

…/…

ends with

:10770800CDCC4C3EFFFFFFFFFFFFFFFFFFFFFFFF5A

:10771800FFFFFFFF19FCFFFF3C7107084A710708CC

:04772800010000005C

:040000050804C0002B

:00000001FF

This is an Hex file format, I guess.

I have programs on slots 3 (Frequency meter) and 4 (Spawn). Is this a problem?



Please may I have you help, to know where I made a mistake?



Thanks again for help,

Hervé

How does Dcf77 works?



Edit: Not in general but on DSO Quad. You need some receiver or you need only antenna and dos acts as SDR?


If you are downloading from the github, check to see that you have selected the “Raw” option on the web interface. Then Right click and “save-as”. The hex file should be no larger than 1xx kb. I had this problem earlier and now know how to avoid it :wink:

Surprisingly the size of current HEX is about 500kB, 500kB is also the size of DFU drive. I noticed, when I was adding more features, the hex file became too large to upload it through DFU. But the file on github is small enough to fit the empty DFU drive. Please check whether the drive is empty (try showing also the hidden files), currently I am working on new bootloader, but I need some more time to finish it. It allows the user to upload HEX or ELF file and flash it & run directly from the user interface.



For the DCF77 module, you need to set the trigger to SCAN, timebase to lowest possible (200ns/div) and set the trigger to reasonable level. I tested it with old broken LCD clock, I put the CH1 probe to the output signal of DCF module and it worked well. So generally speaking - you need either standalone DCF module or disassembled digital clock. DCF modules usually have two digital signals - one as chip select and the second produces square signal - the pulse length is 100ms for ‘0’ or 200ms for ‘1’, single bit is transmitted each second, the pulse should have positive polarity (idle = low voltage, pulse = high). Set the trigger level in middle of these voltages.

As a quick fix, you could divide the program into two .HEX files.



Basically to do that:


  1. Cut the file in half at any line which begins with :02000004 (set address). Cut & paste this line and the rest of the file to a new file.
  2. At the end of the first file, add the line :00000001FF (end of file)

Hi gabonator,



would your firmware run on the hardware version HW2.7 as well or just on HW2.6?



Kind regards,



Axel

Dear Gabonator,



My DFU V3_10_D : Is fully empty even looking at hiden files.



I’ve cut the file before each start adress beginning with :02000004 . adding end mark :00000001FF (end of file) at the end of each file.



I’ve got the RDY file back each time I published the HEX into the HDD of the DSO Quad.



Strangelly, at reboot, I always have my past application at Slot 1, as if your muliple HEX files were not writen.



Any idea?

Do you reboot in transfer mode the DSO between two files written to the DSO? Or do you add them one after one without rebooting?



Thx for help,

Sincerely,

Hervé

galmiche, try downloading older revision of the HEX file. In the github, go to Bin folder and click on history button, there you can select any older revision and browse its repository. For example, select “browse code” for Jan 27, 2013 and then download HEX file from this version. The older revision, the smaller hex :slight_smile:

Hi, I’d really like to try the app but each time I flash it the DSO comes back with .err file. I attempted older hex files that were slightly smaller (433k or so) with the same results. I have no issues loading the latest community edition though. Am I missing something? :?

I reinstalled the latest community edition files as well as FPGA firmware and now I was able to install gabonator’s app.



I’ve got to say I most definately looked like this :smiley: after I run through the GUI. It is very well though out and very responsive. Even the candy look is there! :mrgreen:



That is some pretty high quality work.

I can confirm that this works in hw2.7, but the uploading of the hex file from git is currently problematic. I deleted the html headers and footers but the file was still secretly a txt file and not a hex.



No matter what I did, win7 would add a secret .txt after the .hex so even though you see APP_G251.hex, it is actually APP_G251.hex.txt. This causes an error when uploading the file. The error will be, “Item not found, the item is no longer in computer” which seems to be caused by the dso203 rejecting the txt file.



My workaround solution to this was to download the whole zipped repository from git hub and then upload the .hex file from the bin directory into the drive named DFU V3_11_C on the DSO203. Note that the hw2.7 drive name has changed but that it doesn’t matter.



Upload was successful and now that I’ve contributed my little bit I’m off to play with my new toy. Thanks all. We’re standing on the shoulders of giants.

If you like to experiment, try latest version. In the user modules there is a file browser that can flash HEX files, FPGA images and ELF files (only experimental) directly without restarting into DFU mode. When flashing any image keep in mind that it must be built for slot 2, 3, or 4. Slot 1 is used by my firmware. I tested it with the tetris, jpa’s logic analyser & pawn, and it seems working pretty well.