On Fri, 24 Jul 2015 14:25:07 -0300, YD <ydtechHAT@techie.com> wrote:>On Thu, 23 Jul 2015 11:18:09 -0700, sipping burgundy and listening to >Mahler, >John Larkin <jlarkin@highlandtechnology.com> wrote: > >> >> >>I'm designing a tachometer box and it will have a web page interface >>as one way to talk to it. I thought it would be cool to include an ADC >>so we could display waveforms, too. My software guys here are mostly >>embedded types so we don't know a lot about Javascript and such. I did >>a little searching and mostly found things for displaying audio >>envelope cartoons; I want a real oscilloscope-looking thing, so users >>can see what happens as they change gains and filtering and trigger >>level settings. Dual trace would be nice, the analog waveform and >>corresponding comparator outputs. >> >>Has anybody done this? We'd consider getting outside help, either >>advice or actual coding. >> >>I assume our box will, through some port, deliver HTML, Javascript, >>and maybe some zipped JS libraries to the browser. And the company >>logo of course. The browser will send us text strings to parse if the >>user wants to change parameters or such. We would also deliver blocks >>of waveform data on request. That's my PHB perspective on things; I'm >>just the hardware designer. > >Actionscript running in the Flash plugin should be able to do it >better than Java or JS. Use the free Flashdevelop editor and compiler. >I've done some neat stuff with it. The learning curve is horrendous. A >PHP or Perl script on the server end formats and sends off data blocks >on request. Or have it streaming continously. > >- YD.I heard that Flash is on the way out. And I think that a lot of my customers may not install Flash. Horrendous learning curves will be hard to sell here, too. http://q13fox.com/2015/07/14/firefox-blocks-flash-and-facebook-calls-for-its-death/ -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
waveform display in browser
Started by ●July 23, 2015
Reply by ●July 24, 20152015-07-24
Reply by ●July 24, 20152015-07-24
On 7/24/2015 1:55 PM, John Larkin wrote:> On Fri, 24 Jul 2015 14:25:07 -0300, YD <ydtechHAT@techie.com> wrote: > >> On Thu, 23 Jul 2015 11:18:09 -0700, sipping burgundy and listening to >> Mahler, >> John Larkin <jlarkin@highlandtechnology.com> wrote: >> >>> >>> >>> I'm designing a tachometer box and it will have a web page interface >>> as one way to talk to it. I thought it would be cool to include an ADC >>> so we could display waveforms, too. My software guys here are mostly >>> embedded types so we don't know a lot about Javascript and such. I did >>> a little searching and mostly found things for displaying audio >>> envelope cartoons; I want a real oscilloscope-looking thing, so users >>> can see what happens as they change gains and filtering and trigger >>> level settings. Dual trace would be nice, the analog waveform and >>> corresponding comparator outputs. >>> >>> Has anybody done this? We'd consider getting outside help, either >>> advice or actual coding. >>> >>> I assume our box will, through some port, deliver HTML, Javascript, >>> and maybe some zipped JS libraries to the browser. And the company >>> logo of course. The browser will send us text strings to parse if the >>> user wants to change parameters or such. We would also deliver blocks >>> of waveform data on request. That's my PHB perspective on things; I'm >>> just the hardware designer. >> >> Actionscript running in the Flash plugin should be able to do it >> better than Java or JS. Use the free Flashdevelop editor and compiler. >> I've done some neat stuff with it. The learning curve is horrendous. A >> PHP or Perl script on the server end formats and sends off data blocks >> on request. Or have it streaming continously. >> >> - YD. > > I heard that Flash is on the way out. And I think that a lot of my > customers may not install Flash. > > Horrendous learning curves will be hard to sell here, too. > > http://q13fox.com/2015/07/14/firefox-blocks-flash-and-facebook-calls-for-its-death/I wasn't aware of the reports of its death, perhaps like Mark Twain's, greatly exaggerated. I am no fan for sure. It is for sure the buggiest software on my computer and reminds me of my days with Windows 95 eventually reaching a MTBF of mere hours. -- Rick
Reply by ●July 24, 20152015-07-24
On 2015-07-24, John Larkin <jlarkin@highlandtechnology.com> wrote:> I heard that Flash is on the way out. And I think that a lot of my > customers may not install Flash.If you do it in Flash, it won't work on iPads, or in the current version of Firefox (which blocks flash), or in any browser configured by sane people everywhere.> Horrendous learning curves will be hard to sell here, too. > > http://q13fox.com/2015/07/14/firefox-blocks-flash-and-facebook-calls-for-its-death/Flash is a giant security hole, and the more your site uses flash the more it will be despised by technical people the world over. -- Grant Edwards grant.b.edwards Yow! Everywhere I look I at see NEGATIVITY and ASPHALT gmail.com ...
Reply by ●July 24, 20152015-07-24
On 07/24/2015 01:55 PM, John Larkin wrote:> On Fri, 24 Jul 2015 14:25:07 -0300, YD <ydtechHAT@techie.com> wrote: > >> On Thu, 23 Jul 2015 11:18:09 -0700, sipping burgundy and listening to >> Mahler, >> John Larkin <jlarkin@highlandtechnology.com> wrote: >> >>> >>> >>> I'm designing a tachometer box and it will have a web page interface >>> as one way to talk to it. I thought it would be cool to include an ADC >>> so we could display waveforms, too. My software guys here are mostly >>> embedded types so we don't know a lot about Javascript and such. I did >>> a little searching and mostly found things for displaying audio >>> envelope cartoons; I want a real oscilloscope-looking thing, so users >>> can see what happens as they change gains and filtering and trigger >>> level settings. Dual trace would be nice, the analog waveform and >>> corresponding comparator outputs. >>> >>> Has anybody done this? We'd consider getting outside help, either >>> advice or actual coding. >>> >>> I assume our box will, through some port, deliver HTML, Javascript, >>> and maybe some zipped JS libraries to the browser. And the company >>> logo of course. The browser will send us text strings to parse if the >>> user wants to change parameters or such. We would also deliver blocks >>> of waveform data on request. That's my PHB perspective on things; I'm >>> just the hardware designer. >> >> Actionscript running in the Flash plugin should be able to do it >> better than Java or JS. Use the free Flashdevelop editor and compiler. >> I've done some neat stuff with it. The learning curve is horrendous. A >> PHP or Perl script on the server end formats and sends off data blocks >> on request. Or have it streaming continously. >> >> - YD. > > I heard that Flash is on the way out. And I think that a lot of my > customers may not install Flash. > > Horrendous learning curves will be hard to sell here, too. > > http://q13fox.com/2015/07/14/firefox-blocks-flash-and-facebook-calls-for-its-death/ > >Yeah, there are way too many Flash vulnerabilities. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by ●July 24, 20152015-07-24
On Thu, 23 Jul 2015 19:56:41 -0400, Phil Hobbs wrote:> On 7/23/2015 7:22 PM, John Larkin wrote: >> On Thu, 23 Jul 2015 17:54:47 -0500, Tim Wescott >> <seemywebsite@myfooter.really> wrote: >> >>> On Thu, 23 Jul 2015 15:30:11 -0700, John Larkin wrote: >>> >>>> On Fri, 24 Jul 2015 01:19:09 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>> wrote: >>>> >>>>> On 24.7.2015 ?. 00:50, John Larkin wrote: >>>>>> On Fri, 24 Jul 2015 00:13:19 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>> wrote: >>>>>> >>>>>>> On 23.7.2015 ?. 23:49, rickman wrote: >>>>>>>> On 7/23/2015 4:34 PM, Phil Hobbs wrote: >>>>>>>>> On 7/23/2015 2:18 PM, John Larkin wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm designing a tachometer box and it will have a web page >>>>>>>>>> interface as one way to talk to it. I thought it would be cool >>>>>>>>>> to include an ADC so we could display waveforms, too. My >>>>>>>>>> software guys here are mostly embedded types so we don't know a >>>>>>>>>> lot about Javascript and such. I did a little searching and >>>>>>>>>> mostly found things for displaying audio envelope cartoons; I >>>>>>>>>> want a real oscilloscope-looking thing, so users can see what >>>>>>>>>> happens as they change gains and filtering and trigger level >>>>>>>>>> settings. Dual trace would be nice, the analog waveform and >>>>>>>>>> corresponding comparator outputs. >>>>>>>>>> >>>>>>>>>> Has anybody done this? We'd consider getting outside help, >>>>>>>>>> either advice or actual coding. >>>>>>>>>> >>>>>>>>>> I assume our box will, through some port, deliver HTML, >>>>>>>>>> Javascript, and maybe some zipped JS libraries to the browser. >>>>>>>>>> And the company logo of course. The browser will send us text >>>>>>>>>> strings to parse if the user wants to change parameters or >>>>>>>>>> such. We would also deliver blocks of waveform data on request. >>>>>>>>>> That's my PHB perspective on things; I'm just the hardware >>>>>>>>>> designer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> One approach is a CGI script that runs gnuplot under the covers. >>>>>>>>> IIRC quite a few folks do that. (I'm a static HTML guy myself.) >>>>>>>> >>>>>>>> Isn't there an actual oscilloscope display package under Linux? >>>>>>>> It should be fairly straightforward to drive that from an >>>>>>>> internet connection. I guess requiring the customer to >>>>>>>> installing such a package is not preferred. >>>>>>>> >>>>>>>> >>>>>>> He is after a browser plugin - something like VNC, the way I do it >>>>>>> on our spectrometers (I do not use a plugin but I could if I >>>>>>> wanted to). >>>>>> >>>>>> Actually, I don't want a plugin, just a way for the browser to >>>>>> display a waveform, using some javascript. We can store any >>>>>> reasonable zipped javascript libraries in our gadget and deliver >>>>>> them to the browser. >>>>> >>>>> I am not sure I have seen that done for live graphics - then >>>>> scaling, perhaps autoranging etc., even if doable it would be a >>>>> massive pain to support with all browsers as they keep on evolving. >>>>> Your best bet might be to produce locally a .gif (or .png or >>>>> whatever) >>>>> bitmap, maintain it live and persuade the browser to refresh it >>>>> regularly. Don't know how the latter is to be done though. >>>> >>>> We could do that in the FPGA! If nobody murders me for suggesting it. >>> >>> I don't know how to persuade a browser to auto-refresh, but GIF format >>> uses run-length limiting for compression. That means that line >>> drawings of few colors tend to be very small -- you'll use up way more >>> bits on text than on the pictures. >> >> There is some simple HTML thing that makes a page reload periodically. >> That's apparently easy to do. >> >> A BMP would be easy to make inside the FPGA, but that would be slow to >> load. Maybe the ARM could make a GIF or PNG. That would avoid all the >> javascript nonsense. We'd just have to find the code somewhere. >> >> This bmp is 556K bytes. >> >> https://dl.dropboxusercontent.com/u/53724080/Circuits/Current_Limiters/LM317L_ilim.bmp>> >> That wouldn't be really terrible to send once a second or so over 100 >> MBPS Ethernet. But my FPGA doesn't have enough RAM. >> >> > Bumpfiles are simple, so that's a win. I usually generate those in my > code, then (in a script) call ImageMagick's 'convert' to make them into > .jpg or .png or whatever. > > Cheers > > Phil [system("convert foo.bmp foo.png") covers a multitude of sins]HobbsKinda hard for John to do since he has no OS (if I remember this whole thread well enough). -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 24, 20152015-07-24
On Thu, 23 Jul 2015 16:22:04 -0700, John Larkin wrote:> On Thu, 23 Jul 2015 17:54:47 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>On Thu, 23 Jul 2015 15:30:11 -0700, John Larkin wrote: >> >>> On Fri, 24 Jul 2015 01:19:09 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>> wrote: >>> >>>>On 24.7.2015 ?. 00:50, John Larkin wrote: >>>>> On Fri, 24 Jul 2015 00:13:19 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>> wrote: >>>>> >>>>>> On 23.7.2015 ?. 23:49, rickman wrote: >>>>>>> On 7/23/2015 4:34 PM, Phil Hobbs wrote: >>>>>>>> On 7/23/2015 2:18 PM, John Larkin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm designing a tachometer box and it will have a web page >>>>>>>>> interface as one way to talk to it. I thought it would be cool >>>>>>>>> to include an ADC so we could display waveforms, too. My >>>>>>>>> software guys here are mostly embedded types so we don't know a >>>>>>>>> lot about Javascript and such. I did a little searching and >>>>>>>>> mostly found things for displaying audio envelope cartoons; I >>>>>>>>> want a real oscilloscope-looking thing, so users can see what >>>>>>>>> happens as they change gains and filtering and trigger level >>>>>>>>> settings. Dual trace would be nice, the analog waveform and >>>>>>>>> corresponding comparator outputs. >>>>>>>>> >>>>>>>>> Has anybody done this? We'd consider getting outside help, >>>>>>>>> either advice or actual coding. >>>>>>>>> >>>>>>>>> I assume our box will, through some port, deliver HTML, >>>>>>>>> Javascript, and maybe some zipped JS libraries to the browser. >>>>>>>>> And the company logo of course. The browser will send us text >>>>>>>>> strings to parse if the user wants to change parameters or such. >>>>>>>>> We would also deliver blocks of waveform data on request. That's >>>>>>>>> my PHB perspective on things; I'm just the hardware designer. >>>>>>>>> >>>>>>>>> >>>>>>>> One approach is a CGI script that runs gnuplot under the covers. >>>>>>>> IIRC quite a few folks do that. (I'm a static HTML guy myself.) >>>>>>> >>>>>>> Isn't there an actual oscilloscope display package under Linux? >>>>>>> It should be fairly straightforward to drive that from an internet >>>>>>> connection. I guess requiring the customer to installing such a >>>>>>> package is not preferred. >>>>>>> >>>>>>> >>>>>> He is after a browser plugin - something like VNC, the way I do it >>>>>> on our spectrometers (I do not use a plugin but I could if I wanted >>>>>> to). >>>>> >>>>> Actually, I don't want a plugin, just a way for the browser to >>>>> display a waveform, using some javascript. We can store any >>>>> reasonable zipped javascript libraries in our gadget and deliver >>>>> them to the browser. >>>> >>>>I am not sure I have seen that done for live graphics - then scaling, >>>>perhaps autoranging etc., even if doable it would be a massive pain to >>>>support with all browsers as they keep on evolving. >>>>Your best bet might be to produce locally a .gif (or .png or whatever) >>>>bitmap, maintain it live and persuade the browser to refresh it >>>>regularly. Don't know how the latter is to be done though. >>> >>> We could do that in the FPGA! If nobody murders me for suggesting it. >> >>I don't know how to persuade a browser to auto-refresh, but GIF format >>uses run-length limiting for compression. That means that line drawings >>of few colors tend to be very small -- you'll use up way more bits on >>text than on the pictures. > > There is some simple HTML thing that makes a page reload periodically. > That's apparently easy to do. > > A BMP would be easy to make inside the FPGA, but that would be slow to > load. Maybe the ARM could make a GIF or PNG. That would avoid all the > javascript nonsense. We'd just have to find the code somewhere. > > This bmp is 556K bytes. > > https://dl.dropboxusercontent.com/u/53724080/Circuits/Current_Limiters/LM317L_ilim.bmp> > That wouldn't be really terrible to send once a second or so over 100 > MBPS Ethernet. But my FPGA doesn't have enough RAM.I haven't personally done this, but I've poked at it, and an office-mate of mine did it, before all the file conversion stuff was readily available. If I recall correctly, GIF encoding is on the lines of 100 black, 1 white, 25 black, etc., for each line. So if you could generate a bmp in your FPGA, you could generate the meat of a GIF almost as easily, then have the ARM processor wrap it with the appropriate header and footer and send it out. I'll even do it for you -- if you wait until November for me to get started on it. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 24, 20152015-07-24
On Thu, 23 Jul 2015 16:22:04 -0700, John Larkin wrote:> On Thu, 23 Jul 2015 17:54:47 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>On Thu, 23 Jul 2015 15:30:11 -0700, John Larkin wrote: >> >>> On Fri, 24 Jul 2015 01:19:09 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>> wrote: >>> >>>>On 24.7.2015 ?. 00:50, John Larkin wrote: >>>>> On Fri, 24 Jul 2015 00:13:19 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>> wrote: >>>>> >>>>>> On 23.7.2015 ?. 23:49, rickman wrote: >>>>>>> On 7/23/2015 4:34 PM, Phil Hobbs wrote: >>>>>>>> On 7/23/2015 2:18 PM, John Larkin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm designing a tachometer box and it will have a web page >>>>>>>>> interface as one way to talk to it. I thought it would be cool >>>>>>>>> to include an ADC so we could display waveforms, too. My >>>>>>>>> software guys here are mostly embedded types so we don't know a >>>>>>>>> lot about Javascript and such. I did a little searching and >>>>>>>>> mostly found things for displaying audio envelope cartoons; I >>>>>>>>> want a real oscilloscope-looking thing, so users can see what >>>>>>>>> happens as they change gains and filtering and trigger level >>>>>>>>> settings. Dual trace would be nice, the analog waveform and >>>>>>>>> corresponding comparator outputs. >>>>>>>>> >>>>>>>>> Has anybody done this? We'd consider getting outside help, >>>>>>>>> either advice or actual coding. >>>>>>>>> >>>>>>>>> I assume our box will, through some port, deliver HTML, >>>>>>>>> Javascript, and maybe some zipped JS libraries to the browser. >>>>>>>>> And the company logo of course. The browser will send us text >>>>>>>>> strings to parse if the user wants to change parameters or such. >>>>>>>>> We would also deliver blocks of waveform data on request. That's >>>>>>>>> my PHB perspective on things; I'm just the hardware designer. >>>>>>>>> >>>>>>>>> >>>>>>>> One approach is a CGI script that runs gnuplot under the covers. >>>>>>>> IIRC quite a few folks do that. (I'm a static HTML guy myself.) >>>>>>> >>>>>>> Isn't there an actual oscilloscope display package under Linux? >>>>>>> It should be fairly straightforward to drive that from an internet >>>>>>> connection. I guess requiring the customer to installing such a >>>>>>> package is not preferred. >>>>>>> >>>>>>> >>>>>> He is after a browser plugin - something like VNC, the way I do it >>>>>> on our spectrometers (I do not use a plugin but I could if I wanted >>>>>> to). >>>>> >>>>> Actually, I don't want a plugin, just a way for the browser to >>>>> display a waveform, using some javascript. We can store any >>>>> reasonable zipped javascript libraries in our gadget and deliver >>>>> them to the browser. >>>> >>>>I am not sure I have seen that done for live graphics - then scaling, >>>>perhaps autoranging etc., even if doable it would be a massive pain to >>>>support with all browsers as they keep on evolving. >>>>Your best bet might be to produce locally a .gif (or .png or whatever) >>>>bitmap, maintain it live and persuade the browser to refresh it >>>>regularly. Don't know how the latter is to be done though. >>> >>> We could do that in the FPGA! If nobody murders me for suggesting it. >> >>I don't know how to persuade a browser to auto-refresh, but GIF format >>uses run-length limiting for compression. That means that line drawings >>of few colors tend to be very small -- you'll use up way more bits on >>text than on the pictures. > > There is some simple HTML thing that makes a page reload periodically. > That's apparently easy to do. > > A BMP would be easy to make inside the FPGA, but that would be slow to > load. Maybe the ARM could make a GIF or PNG. That would avoid all the > javascript nonsense. We'd just have to find the code somewhere. > > This bmp is 556K bytes. > > https://dl.dropboxusercontent.com/u/53724080/Circuits/Current_Limiters/LM317L_ilim.bmp> > That wouldn't be really terrible to send once a second or so over 100 > MBPS Ethernet. But my FPGA doesn't have enough RAM.Whoops -- it's LZW encoding. It should still be fairly easy to implement, possibly even in FPGA-land. And, if not, there's probably code chunks out there in C. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 24, 20152015-07-24
On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:> If I recall correctly, GIF encoding is on the lines of > > 100 black, 1 white, 25 black, etc., for each line.That's call run-length encoding, and it's what TIFF uses. GIF files are encoded as 8-bits-per-pixel (with a 256-byte color lookup table), and then compressed using the Lempel-Ziv-Welch algorithm. https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch> So if you could generate a bmp in your FPGA, you could generate the meat > of a GIF almost as easily, then have the ARM processor wrap it with the > appropriate header and footer and send it out.Implementing LZW in an FPGA would be a daunting, but people have done it.> I'll even do it for you -- if you wait until November for me to get > started on it.-- Grant Edwards grant.b.edwards Yow! Gee, I feel kind of at LIGHT in the head now, gmail.com knowing I can't make my satellite dish PAYMENTS!
Reply by ●July 24, 20152015-07-24
On Fri, 24 Jul 2015 14:55:50 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote:>On Thu, 23 Jul 2015 19:56:41 -0400, Phil Hobbs wrote: > >> On 7/23/2015 7:22 PM, John Larkin wrote: >>> On Thu, 23 Jul 2015 17:54:47 -0500, Tim Wescott >>> <seemywebsite@myfooter.really> wrote: >>> >>>> On Thu, 23 Jul 2015 15:30:11 -0700, John Larkin wrote: >>>> >>>>> On Fri, 24 Jul 2015 01:19:09 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>> wrote: >>>>> >>>>>> On 24.7.2015 ?. 00:50, John Larkin wrote: >>>>>>> On Fri, 24 Jul 2015 00:13:19 +0300, Dimiter_Popoff <dp@tgi-sci.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On 23.7.2015 ?. 23:49, rickman wrote: >>>>>>>>> On 7/23/2015 4:34 PM, Phil Hobbs wrote: >>>>>>>>>> On 7/23/2015 2:18 PM, John Larkin wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm designing a tachometer box and it will have a web page >>>>>>>>>>> interface as one way to talk to it. I thought it would be cool >>>>>>>>>>> to include an ADC so we could display waveforms, too. My >>>>>>>>>>> software guys here are mostly embedded types so we don't know a >>>>>>>>>>> lot about Javascript and such. I did a little searching and >>>>>>>>>>> mostly found things for displaying audio envelope cartoons; I >>>>>>>>>>> want a real oscilloscope-looking thing, so users can see what >>>>>>>>>>> happens as they change gains and filtering and trigger level >>>>>>>>>>> settings. Dual trace would be nice, the analog waveform and >>>>>>>>>>> corresponding comparator outputs. >>>>>>>>>>> >>>>>>>>>>> Has anybody done this? We'd consider getting outside help, >>>>>>>>>>> either advice or actual coding. >>>>>>>>>>> >>>>>>>>>>> I assume our box will, through some port, deliver HTML, >>>>>>>>>>> Javascript, and maybe some zipped JS libraries to the browser. >>>>>>>>>>> And the company logo of course. The browser will send us text >>>>>>>>>>> strings to parse if the user wants to change parameters or >>>>>>>>>>> such. We would also deliver blocks of waveform data on request. >>>>>>>>>>> That's my PHB perspective on things; I'm just the hardware >>>>>>>>>>> designer. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> One approach is a CGI script that runs gnuplot under the covers. >>>>>>>>>> IIRC quite a few folks do that. (I'm a static HTML guy myself.) >>>>>>>>> >>>>>>>>> Isn't there an actual oscilloscope display package under Linux? >>>>>>>>> It should be fairly straightforward to drive that from an >>>>>>>>> internet connection. I guess requiring the customer to >>>>>>>>> installing such a package is not preferred. >>>>>>>>> >>>>>>>>> >>>>>>>> He is after a browser plugin - something like VNC, the way I do it >>>>>>>> on our spectrometers (I do not use a plugin but I could if I >>>>>>>> wanted to). >>>>>>> >>>>>>> Actually, I don't want a plugin, just a way for the browser to >>>>>>> display a waveform, using some javascript. We can store any >>>>>>> reasonable zipped javascript libraries in our gadget and deliver >>>>>>> them to the browser. >>>>>> >>>>>> I am not sure I have seen that done for live graphics - then >>>>>> scaling, perhaps autoranging etc., even if doable it would be a >>>>>> massive pain to support with all browsers as they keep on evolving. >>>>>> Your best bet might be to produce locally a .gif (or .png or >>>>>> whatever) >>>>>> bitmap, maintain it live and persuade the browser to refresh it >>>>>> regularly. Don't know how the latter is to be done though. >>>>> >>>>> We could do that in the FPGA! If nobody murders me for suggesting it. >>>> >>>> I don't know how to persuade a browser to auto-refresh, but GIF format >>>> uses run-length limiting for compression. That means that line >>>> drawings of few colors tend to be very small -- you'll use up way more >>>> bits on text than on the pictures. >>> >>> There is some simple HTML thing that makes a page reload periodically. >>> That's apparently easy to do. >>> >>> A BMP would be easy to make inside the FPGA, but that would be slow to >>> load. Maybe the ARM could make a GIF or PNG. That would avoid all the >>> javascript nonsense. We'd just have to find the code somewhere. >>> >>> This bmp is 556K bytes. >>> >>> https://dl.dropboxusercontent.com/u/53724080/Circuits/Current_Limiters/ >LM317L_ilim.bmp >>> >>> That wouldn't be really terrible to send once a second or so over 100 >>> MBPS Ethernet. But my FPGA doesn't have enough RAM. >>> >>> >> Bumpfiles are simple, so that's a win. I usually generate those in my >> code, then (in a script) call ImageMagick's 'convert' to make them into >> .jpg or .png or whatever. >> >> Cheers >> >> Phil [system("convert foo.bmp foo.png") covers a multitude of sins]Hobbs > >Kinda hard for John to do since he has no OS (if I remember this whole >thread well enough).And I won't have much ram; 256K bytes in the ARM, and some in the FPGA, but not enough to store an entire bmp anywhere. SVG looks good so far; all we'd have to do is send the data points, as text, not an image. A couple of kbytes might do it. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by ●July 24, 20152015-07-24
On Fri, 24 Jul 2015 20:15:21 +0000, Grant Edwards wrote:> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote: > >> If I recall correctly, GIF encoding is on the lines of >> >> 100 black, 1 white, 25 black, etc., for each line. > > That's call run-length encoding, and it's what TIFF uses. > > GIF files are encoded as 8-bits-per-pixel (with a 256-byte color lookup > table), and then compressed using the Lempel-Ziv-Welch algorithm. > > https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93WelchHuh. I musta had TIFF and GIF confused. TIFF may be suitable, if John doesn't end up using SVG.>> So if you could generate a bmp in your FPGA, you could generate the >> meat of a GIF almost as easily, then have the ARM processor wrap it >> with the appropriate header and footer and send it out. > > Implementing LZW in an FPGA would be a daunting, but people have done > it.I'm not so sure it would be all that bad, if you were writing something specific to GIF format.>> I'll even do it for you -- if you wait until November for me to get >> started on it.My offer still stands, GIF or TIFF. John's looking at SVG, which isn't a bad choice if it's universal. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
