Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #21464 > unrolled thread

waveform display in browser

Back to article view | Back to comp.arch.embedded

Contents

  waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-23 11:18 -0700
    Re: waveform display in browser Joerg <news@analogconsultants.com> - 2015-07-23 11:53 -0700
    Re: waveform display in browser Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2015-07-23 16:34 -0400
      Re: waveform display in browser rickman <gnuarm@gmail.com> - 2015-07-23 16:49 -0400
        Re: waveform display in browser Dimiter_Popoff <dp@tgi-sci.com> - 2015-07-24 00:13 +0300
          Re: waveform display in browser rickman <gnuarm@gmail.com> - 2015-07-23 17:39 -0400
          Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-23 14:50 -0700
            Re: waveform display in browser Dimiter_Popoff <dp@tgi-sci.com> - 2015-07-24 01:19 +0300
              Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-23 15:30 -0700
                Re: waveform display in browser rickman <gnuarm@gmail.com> - 2015-07-23 18:46 -0400
                Re: waveform display in browser Tim Wescott <seemywebsite@myfooter.really> - 2015-07-23 17:54 -0500
                  Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-23 16:22 -0700
                    Re: waveform display in browser Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2015-07-23 19:56 -0400
                      Re: waveform display in browser Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 14:55 -0500
                        Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-24 14:11 -0700
                          Re: waveform display in browser Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 17:00 -0500
                          Re: waveform display in browser Herbert Kleebauer <klee@unibwm.de> - 2015-07-25 09:04 +0200
                    Re: waveform display in browser Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 14:58 -0500
                      Re: waveform display in browser Grant Edwards <invalid@invalid.invalid> - 2015-07-24 20:15 +0000
                        Re: waveform display in browser Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 16:48 -0500
                          Re: waveform display in browser Grant Edwards <invalid@invalid.invalid> - 2015-07-24 22:08 +0000
                            Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-24 22:46 +1000
                              Re: waveform display in browser Grant Edwards <invalid@invalid.invalid> - 2015-07-25 14:32 +0000
                        Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-24 22:44 +0000
                          Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-24 23:31 +0000
                          Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-24 22:49 +1000
                            Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-25 09:28 +0000
                              Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-25 08:43 +1000
                                Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-25 22:27 +0000
                                  Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-25 20:57 +1000
                      Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-24 22:41 +0000
                        Re: waveform display in browser rickman <gnuarm@gmail.com> - 2015-07-24 22:03 -0400
                    Re: waveform display in browser Tim Wescott <seemywebsite@myfooter.really> - 2015-07-24 15:05 -0500
    Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-23 21:37 +0000
      Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-23 15:32 -0700
    Re: waveform display in browser Martin Riddle <martin_ridd@verizon.net> - 2015-07-23 20:24 -0400
      Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-23 21:08 -0700
        Re: waveform display in browser Martin Riddle <martin_ridd@verizon.net> - 2015-07-24 07:52 -0400
          Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-24 14:08 +0000
            Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-24 22:53 +1000
              Re: waveform display in browser Jasen Betts <jasen@xnet.co.nz> - 2015-07-25 09:46 +0000
                Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-25 08:46 +1000
    Re: waveform display in browser Clifford Heath <no.spam@please.net> - 2015-07-24 00:37 +1000
    Re: waveform display in browser Martin Brown <|||newspam|||@nezumi.demon.co.uk> - 2015-07-24 11:46 +0100
    Re: waveform display in browser YD <ydtechHAT@techie.com> - 2015-07-24 14:25 -0300
      Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-24 10:55 -0700
        Re: waveform display in browser rickman <gnuarm@gmail.com> - 2015-07-24 14:09 -0400
        Re: waveform display in browser Grant Edwards <invalid@invalid.invalid> - 2015-07-24 18:42 +0000
          Re: waveform display in browser YD <ydtechHAT@techie.com> - 2015-07-24 19:12 -0300
            Re: waveform display in browser Grant Edwards <invalid@invalid.invalid> - 2015-07-25 14:36 +0000
        Re: waveform display in browser Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2015-07-24 14:55 -0400
    Re: waveform display in browser John Larkin <jlarkin@highlandtechnology.com> - 2015-07-27 17:52 -0700
      Re: waveform display in browser Phil Hobbs <hobbs@electrooptical.net> - 2015-07-28 17:58 -0400
    Re: waveform display in browser "jurem" <51422@EmbeddedRelated> - 2015-07-28 09:49 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#21517

On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Fri, 24 Jul 2015 20:15:21 +0000, Grant Edwards wrote:
>
>> 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 think you're right.  It sounded nasty to me based on the
descriptions of the LZW that I remember, but according to Google there
have been a lot of people who've done it.

>>> 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.

SVG is pretty nice, but until the past couple years, SVG support in
browsers was pretty iffy.  If you don't have to support old browser
versions, SVG is worth looking at.

-- 
Grant Edwards               grant.b.edwards        Yow! over in west
                                  at               Philadelphia a puppy is
                              gmail.com            vomiting ...

[toc] | [prev] | [next] | [standalone]

#21526

On 25/07/15 08:08, Grant Edwards wrote:
> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:
>> My offer still stands, GIF or TIFF.

TIFF is Tagged Image File Format. It's not an compression format, though 
it supports many compressions. With monochrome data, the G4 fax encoding 
is truly spectacular.

You could probably implement GIF with a vestigial compression that 
merely looks like LZW. You wouldn't get any compression, but a reader 
would still find that it's a complying format.

> SVG is pretty nice, but until the past couple years, SVG support in
> browsers was pretty iffy.  If you don't have to support old browser
> versions, SVG is worth looking at.

SVG wasn't available in IE prior to version 8. Other older browsers that 
didn't do SVG have almost all been upgraded, so its reasonable to 
require that.

If you want to use SVG, but fall back to VML back as far as IE5, I 
recommend the Raphael Javascript library at <http://raphaeljs.com>. It 
does what it says on the box. But these days I'm just using SVG.

Clifford Heath

[toc] | [prev] | [next] | [standalone]

#21538

On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
> On 25/07/15 08:08, Grant Edwards wrote:
>> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>> My offer still stands, GIF or TIFF.
>
> TIFF is Tagged Image File Format. It's not an compression format, though 
> it supports many compressions. With monochrome data, the G4 fax encoding 
> is truly spectacular.

I guess the only format I ever worked with in TIFF was the run-length
encoduing used by faxes.  I had forgotten there were other options for
compression.

> SVG wasn't available in IE prior to version 8. Other older browsers
> that didn't do SVG have almost all been upgraded, so its reasonable
> to require that.
>
> If you want to use SVG, but fall back to VML back as far as IE5, I 
> recommend the Raphael Javascript library at <http://raphaeljs.com>. It 
> does what it says on the box. But these days I'm just using SVG.

It's good to hear that SVG support is common enough to be useful.

The last time I needed to do data plots on web pages was something
like 6-7 years ago, and SVG was a bit too bleeding edge at the time.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#21521

On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.

no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )

-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21523

On 2015-07-24, Jasen Betts <jasen@xnet.co.nz> wrote:
> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.
>
> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )
>
i mean per pixel.

-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21527

On 25/07/15 08:44, Jasen Betts wrote:
> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.
>
> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )

That's incorrect. GIF uses an 8-bit (256 element colour map) that has 
3x8-bit RGB elements. The actual image data is 8-bit indices into that 
colour map, LZW compressed - exactly what Grant said.

[toc] | [prev] | [next] | [standalone]

#21534

On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
> On 25/07/15 08:44, Jasen Betts wrote:
>> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.
>>
>> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )
>
> That's incorrect. GIF uses an 8-bit (256 element colour map) that has 
> 3x8-bit RGB elements. The actual image data is 8-bit indices into that 
> colour map, LZW compressed - exactly what Grant said.

You're making shit up.

 I just made a gif file here that's 73 bytes. explain that.

 1 bit per pixel (before compression) monochome gifs were done 
 and other colour depths too. the palette is variable length 
 (I can't remeber if it's fixed to 2^n slots or allowed to be 
 intermediate sizes.
 
 GIF was invented in 1987 when very few people had 8-bit colour
 displays. 

jasen@fozzie:~$ cat 1.pbm
P1
1 1
1 
jasen@fozzie:~$ convert 1.pbm 1.gif
jasen@fozzie:~$ ls -l 1.gif
-rw-r--r-- 1 jasen jasen 73 Jul 25 21:14 1.gif
jasen@fozzie:~$ giftrans -l 1.gif 
Global Color Table:
Color 0: Red 0, Green 0, Blue 0, #000000 (black, gray0, grey0)
Color 1: Red 255, Green 255, Blue 255, #ffffff (white, gray100, grey100)

 
-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21536

On 25/07/15 19:28, Jasen Betts wrote:
> On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
>> On 25/07/15 08:44, Jasen Betts wrote:
>>> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.
>>>
>>> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )
>>
>> That's incorrect. GIF uses an 8-bit (256 element colour map) that has
>> 3x8-bit RGB elements. The actual image data is 8-bit indices into that
>> colour map, LZW compressed - exactly what Grant said.
>
> You're making shit up.
>
>   I just made a gif file here that's 73 bytes. explain that.

The color map doesn't have to be full.

How so you survive in a technical career without being able to use Google?

<https://en.wikipedia.org/wiki/GIF>
<http://www.w3.org/Graphics/GIF/spec-gif89a.txt>
<http://www.matthewflickinger.com/lab/whatsinagif/bits_and_bytes.asp>

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#21540

On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
> On 25/07/15 19:28, Jasen Betts wrote:
>> On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
>>> On 25/07/15 08:44, Jasen Betts wrote:
>>>> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.
>>>>
>>>> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )
>>>
>>> That's incorrect. GIF uses an 8-bit (256 element colour map) that has
>>> 3x8-bit RGB elements. The actual image data is 8-bit indices into that
>>> colour map, LZW compressed - exactly what Grant said.
>>
>> You're making shit up.
>>
>>   I just made a gif file here that's 73 bytes. explain that.
>
> The color map doesn't have to be full.

> How so you survive in a technical career without being able to use Google?

finding the information is only part of the problem, YOU also need to
understand it.

><https://en.wikipedia.org/wiki/GIF>
><http://www.w3.org/Graphics/GIF/spec-gif89a.txt>

That pretty-much as I remember it from the early 90s.

hmm, seaction 19 and section 21. say something very similar to 3*2^N

22. Table Based Image Data.
  "LZW Minimum Code Size"
  
see appendix F for it's significgance
  starting at "ESTABLISH CODE SIZE"
  
what it means is that the actual data is N-bit indices into the color
table, because indices 2^N and above cannot be coded.

if that's too complicated, see this part ot the wikipedia page:
https://en.wikipedia.org/wiki/GIF#LZW_code_lengths

-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21541

On 26/07/15 08:27, Jasen Betts wrote:
> On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
>> On 25/07/15 19:28, Jasen Betts wrote:
>>> On 2015-07-24, Clifford Heath <no.spam@please.net> wrote:
>>>> On 25/07/15 08:44, Jasen Betts wrote:
>>>>> On 2015-07-24, Grant Edwards <invalid@invalid.invalid> 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.
>>>>>
>>>>> no, N bits per colour with a 3*2^N table ( 1 <= N <= 8 )
>>>>
>>>> That's incorrect. GIF uses an 8-bit (256 element colour map) that has
>>>> 3x8-bit RGB elements. The actual image data is 8-bit indices into that
>>>> colour map, LZW compressed - exactly what Grant said.
>>>
>>> You're making shit up.
>>>
>>>    I just made a gif file here that's 73 bytes. explain that.
>>
>> The color map doesn't have to be full.
>
>> How so you survive in a technical career without being able to use Google?
>
> finding the information is only part of the problem, YOU also need to
> understand it.
>
>> <https://en.wikipedia.org/wiki/GIF>
>> <http://www.w3.org/Graphics/GIF/spec-gif89a.txt>
>
> That pretty-much as I remember it from the early 90s.
>
> hmm, seaction 19 and section 21. say something very similar to 3*2^N

Those sections are talking about the color table. The index is still a 
maximum of 8 bits, because it's defined by the 3 bit value (which stores 
the exponent-1).

I thought that your original claim was that each pixel has 3 colours 
independent of any table, but I think I misinterpreted you and we've 
been talking past each other. Sorry about that.


> 22. Table Based Image Data.
>    "LZW Minimum Code Size"
>
> see appendix F for it's significgance
>    starting at "ESTABLISH CODE SIZE"
>
> what it means is that the actual data is N-bit indices into the color
> table, because indices 2^N and above cannot be coded.
>
> if that's too complicated, see this part ot the wikipedia page:
> https://en.wikipedia.org/wiki/GIF#LZW_code_lengths
>

[toc] | [prev] | [next] | [standalone]

#21520

On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Thu, 23 Jul 2015 16:22:04 -0700, John Larkin wrote:
>>
> 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.

No, Gif uses LZW compression not RLE. there was a LZW compatible RLE
encoder, but that was purely a patent dodge.

> So if you could generate a bmp in your FPGA,

you don't need to generate the bitmap first, the pixel colour can be
determine4d algorithmically (eg by running several bresenhan line
algorithms in objects in a heap) gif compression only needs one pixel
at a time. (but why bother, just send coordinates and call it SVG)


-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21530

On 7/24/2015 6:41 PM, Jasen Betts wrote:
> On 2015-07-24, Tim Wescott <seemywebsite@myfooter.really> wrote:
>> On Thu, 23 Jul 2015 16:22:04 -0700, John Larkin wrote:
>>>
>> 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.
>
> No, Gif uses LZW compression not RLE. there was a LZW compatible RLE
> encoder, but that was purely a patent dodge.
>
>> So if you could generate a bmp in your FPGA,
>
> you don't need to generate the bitmap first, the pixel colour can be
> determine4d algorithmically (eg by running several bresenhan line
> algorithms in objects in a heap) gif compression only needs one pixel
> at a time. (but why bother, just send coordinates and call it SVG)

Likewise, the bitmap doesn't need to be generated all at once.  It can 
be generated one pixel at a time and sent out immediately requiring no 
bitmap storage at all.  I considered doing this in a small oscilloscope 
once where the image would be generated in the chip and sent out a port 
rather than stored.  Much of the display is fixed or text with the 
traces impacting the display in an easy to calculate manner... at least 
easy in a chip with many fast ALUs which sounds a lot like an FPGA to me.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21510

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

[toc] | [prev] | [next] | [standalone]

#21475

On 2015-07-23, 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? 

I've used a JS graphing package called "flot" that could probably be
modified to display scrolling or static waveforms. I think it's based
on HTML5 canvas and/or SVG DOM. I made some small tweaks and found it
to be well written.

-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21478

On 23 Jul 2015 21:37:49 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

>On 2015-07-23, 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? 
>
>I've used a JS graphing package called "flot" that could probably be
>modified to display scrolling or static waveforms. I think it's based
>on HTML5 canvas and/or SVG DOM. I made some small tweaks and found it
>to be well written.

Lasse also suggested flot. That looks promising.

Wanna help?


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

[toc] | [prev] | [next] | [standalone]

#21483

On Thu, 23 Jul 2015 11:18:09 -0700, 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.

Java might be a tad slow. SVG might be better.
But thers a bunch of API's out there, search javascript stripcharts.

Cheers

[toc] | [prev] | [next] | [standalone]

#21485

On Thu, 23 Jul 2015 20:24:48 -0400, Martin Riddle
<martin_ridd@verizon.net> wrote:

>On Thu, 23 Jul 2015 11:18:09 -0700, 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.
>
>Java might be a tad slow. SVG might be better.

Yeah, svg looks promising. If I let the FPGA do the acquisition (some
clever auto-trigger-oscilloscope algorithm based on the ADC data?) and
buffer maybe 250 or so points per waveform, the ARM could read that
data and build a not-absurdly long svg/html thing to send back, once a
second maybe.


-- 

John Larkin         Highland Technology, Inc
lunatic fringe electronics

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

[toc] | [prev] | [next] | [standalone]

#21489

On Thu, 23 Jul 2015 21:08:55 -0700, John Larkin
<jlarkin@highlandtechnology.com> wrote:

>On Thu, 23 Jul 2015 20:24:48 -0400, Martin Riddle
><martin_ridd@verizon.net> wrote:
>
>>On Thu, 23 Jul 2015 11:18:09 -0700, 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.
>>
>>Java might be a tad slow. SVG might be better.
>
>Yeah, svg looks promising. If I let the FPGA do the acquisition (some
>clever auto-trigger-oscilloscope algorithm based on the ADC data?) and
>buffer maybe 250 or so points per waveform, the ARM could read that
>data and build a not-absurdly long svg/html thing to send back, once a
>second maybe.

AJAX, works ok. Theres a difference in implemntation between browsers
tho. I used that to send indicator/display information.
Be willing to support future browsers with a firmware update.

Cheers

[toc] | [prev] | [next] | [standalone]

#21491

On 2015-07-24, Martin Riddle <martin_ridd@verizon.net> wrote:
> On Thu, 23 Jul 2015 21:08:55 -0700, John Larkin
><jlarkin@highlandtechnology.com> wrote:
>
>
> AJAX, works ok. Theres a difference in implemntation between browsers
> tho. I used that to send indicator/display information.
> Be willing to support future browsers with a firmware update.

If you get it right you won't need to update. 

Don't guess, follow the standards, it's just like reading a datasheet,
except that errors in the description are fixed by updating the product.

-- 
umop apisdn

[toc] | [prev] | [next] | [standalone]

#21528

On 25/07/15 00:08, Jasen Betts wrote:
> On 2015-07-24, Martin Riddle <martin_ridd@verizon.net> wrote:
>> On Thu, 23 Jul 2015 21:08:55 -0700, John Larkin
>> Be willing to support future browsers with a firmware update.
> If you get it right you won't need to update.
> Don't guess, follow the standards, it's just like reading a datasheet,
> except that errors in the description are fixed by updating the product.

Don't try to read or follow the standards, because those don't tell you 
which browsers diverge from the standard or in what way.

Instead, use a Javascript library that papers over the differences. The 
vast majority of sites now use JQuery for that, and nothing will change 
in the browsers that stops that working properly.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web