Nextion LCD panel

[Andrew Davie]

The irony of using a modern high-resolution LCD bitmap display panel on a televisor, but that's exactly what I'm planning to do! My NX3224TO24 display panel ($16) arrived today, and I plan to use it as a sort of file-selector for the files on my SD card. It will have play and stop, possibly even pause. But also a bit of a blurb about each file and possibly a screenshot. Anyway, it looks pretty cool and easy to use and takes just two pins on the Arduino (RX/TX) with also GND and +5V supply. So I'll have a go at including that on the weekend.
The basic concept is that each NBTV file on the SD will have its own selection screen. The LCD panel shows a list of available files on the SD card, and you can page back and forth between each, where there's some text describing the file (for example, 1933 recording from Television; restoration by blah blah.... etc). And on that screen a play/stop button, or you can go to the next file, etc. Background could be nice colour pictures etc. I'd like my televisor to be a bit like an educational museum piece/display where you could not just play files but learn about what's actualyl happening.
Besides... new toy... I wanted to learn how to drive a LCD panel from the Arduino.

[Klaas Robers]

And how about sync? I have a CD that came with the MUTR televisor, which was not a CD but a CD-ROM containing kind of .wave files. Some CD-players can play that, but when going from one track to the next, there was a hic-up in the sync. Then you see that the disc has to resynchronise. With the small and light disc of the MUTR this went in about 1½ second, but with others this takes more time. Then you loose the first part of the scene.

Of course you can make it such that when there is no file playing, that the disc is kept in digital synchronisation and every file starts and stops exactly on a (missing) sync pulse. More over it is possible to store sync-less video on the SD-card and rely completely on the byte count. Sync pulses are no more needed for synchronisation! You simply start and stop reading from the card when your Arduino detects the single sync hole in the disc. This is something where even J.L.Baird could not have been dreaming of.

And you can have files with sound and files without sound, which will save you 50% of storage capacity in the second case. For the "no sound" files you can even skip storing the wasted time for the no more needed sync pulses. The black bar can be generated in real time by the Arduino on its own. Although this will save you just a few % of storage capacity.

You see? Many new possibilities!

[gary]

youtu.be/_dcrLz5id4A

[Andrew Davie]

Ha! But, most surprisingly I have spare pins everywhere.



MOSI --> MicroSD card reader
SS
1/TX --> LCD
0/RX --> LCD
RESET
GND --> motor circuit GND
2/SDA
3(PWM)/SCL --> motor PWM
4/A6 --> select pin for MicroSD reader
5(PWM)
6(PWM)/A7
7 --> IR sensor comparator input
8/A8
9(PWM)/A9
10(PWM)/A10
11(PWM)
12/A11

13(PWM) --> LED duty
3.3V
AREF
A0
A1
A2
A3
A4
A5
NC
NC
+5V --> IR LED power
RESET
GND --> IR LED GND --> LED GND
VIN
MISO --> MicroSD card reader
SCK --> MicroSD card reader

The pins are shown line by line, above, and those in red are currently unallocated.
I have the Motor, IR sensors, MicroSD card, display LEDs, and the LCD bitmap display connected. And I still have heaps of pins

[gary]

Yep, shields are for pussies.

[Andrew Davie]

Well, the Nextion display worked first-up. It's lovely. I tested the interface - touch-sensitive screen. Works really well.
Here it is sitting on my spare "sacrificial" Arduino test platform. I have to learn how to setup my own UI but the nice thing is that the Arduino does none of the work - the display itself has all the smarts, and the Arduino just polls for button presses. It doesn't do any of the drawing, or require any processing power. Very nice.

nextion.jpg (326.22 KiB) Viewed 12496 times

What a bargain for $16 inclusive of shipping!

[Andrew Davie]

I've now grafted the Nextion onto my main "televisor" and am delighted to see that it's getting enough power to display properly. Apparently only using 90mA, which is impressive (to me, at least!). Anyway, the short video shows the arduino televisor as it stands now - no synch yet, but the video coming from the inbuilt Micro SD card/reader, the Nextion LCD ready for me to put a user interface on-board, and of course the IR and motor stuff all working sufficiently. A side-note - I put a heatsink on my motor's TIP122 and it's much happier now; doesn't seem to be getting hot at all.


youtu.be/yIcNe__UQVg

[Andrew Davie]

Of course I'm going to put the brightness, contrast and vertical adjust controls onto the LCD UI, rather than having pots. This, too, reduces the work for the Arduino.

[Andrew Davie]

And how about sync? I have a CD that came with the MUTR televisor, which was not a CD but a CD-ROM containing kind of .wave files. Some CD-players can play that, but when going from one track to the next, there was a hic-up in the sync. Then you see that the disc has to resynchronise. With the small and light disc of the MUTR this went in about 1½ second, but with others this takes more time. Then you loose the first part of the scene.

Of course you can make it such that when there is no file playing, that the disc is kept in digital synchronisation and every file starts and stops exactly on a (missing) sync pulse. More over it is possible to store sync-less video on the SD-card and rely completely on the byte count. Sync pulses are no more needed for synchronisation! You simply start and stop reading from the card when your Arduino detects the single sync hole in the disc. This is something where even J.L.Baird could not have been dreaming of.

And you can have files with sound and files without sound, which will save you 50% of storage capacity in the second case. For the "no sound" files you can even skip storing the wasted time for the no more needed sync pulses. The black bar can be generated in real time by the Arduino on its own. Although this will save you just a few % of storage capacity.

You see? Many new possibilities!

All of this is true, but I think it depends on what you are aiming to achieve. What I am aiming for is something that is stand-alone, lets you select from a number of representative NBTV tracks, and shows the process of disc spinning up and synchronising. I am happy to have the synch process take a number of seconds, so for me the "seamless" nature of what you are suggesting is actually NOT what I want.

But you are right - I could create my own sync timing - I don't need the pulses at all. I could save storage space (or more importantly speed of access to the MicroSD) by dropping audio, but I don't think I need to do that. With many (32+) GIGAbytes of storage on the card I'm using now, I don't think storage space will EVER be an issue.

I do like the idea, though, of using the byte count for accurate sync - I never considered that, and it would simplify the process considerably - I think I will use this - thanks very much I won't be able to do it quite like you suggest - for reading from the card has seemingly random and unpredictable lag/delay - sometime when I try to read some bytes from the card, I don't get them back for 250ms. That's why my video play system has been having "hiccups". My new system allows for the lag through a number of methods. But it would never (in my opinion) be able to keep in synch with the timing of the disc - you need to read asyncrhronously and have a guaranteed "already in RAM" buffer to play back from.

[gary]

you need to read asyncrhronously and have a guaranteed "already in RAM" buffer to play back from.

Yes Andrew, without Direct Memory Access, double buffering will be problematical, I will be interested in seeing what you come up with.

[Andrew Davie]

you need to read asyncrhronously and have a guaranteed "already in RAM" buffer to play back from.

Yes Andrew, without Direct Memory Access, double buffering will be problematical, I will be interested in seeing what you come up with.

What I have now is pretty good! That is, an interrupt running at 22050 Hz reading from a circular buffer. In the main loop (non-interrupt) there's a polling loop that looks to see if that buffer has any "already played" data, and will read from the SD card to fill up that (variable) amount of space. Because the SD-card read has occasionally a long delay, sometimes filling up that space takes a long time. And to cater for that, make the buffer as big as possible. I have it at 256 bytes at the moment (which at 4 bytes per sample - 2 bytes audio, 2 bytes video - is 64 samples), and it seems to be coping OK. Occasionally there's a glitch, but it's hardly noticeable. I will come back to this issue later, but for now it's good enough.

Note, it's NOT double buffering - it's a circular buffer. This has the advantage of limiting memory use and maximising the amount of data read in advance.

[gary]

Well double buffering, IMHO, is just a minimal circular buffer - think of the ring as having only 2 segments - but my point was, THAT is the minimum you need.

When I code an audio player or recorder it generally has more, but smaller, buffers.

[Andrew Davie]

Well double buffering, IMHO, is just a minimal circular buffer - think of the ring as having only 2 segments - but my point was, THAT is the minimum you need.

When I code an audio player or recorder it generally has more, but smaller, buffers.

Similar but not the same. The majority of the circular buffer (say, 95%) has valid data to play, and thus can cater for a longer period without refresh of the non-valid data. A double-buffer allocates 50% to playable data and 50% to data being read from the source. For a given amount of playable data, a circular buffer can be around half the memory requirement. Another way of saying this; a double-buffer has pre-set sizes for "valid data block to play now" and "loading next data block" - allocated at 50% each. A circular buffer has variable size for the "loading next data block" and the majority of the buffer is typically "valid data block to play now". The circular buffer loads less data more frequently; the double buffer loads more data less frequently - compared to each other, in the implementation I use anyway.

But yes, I think we both know exactly what we're talking about here.

[Klaas Robers]

When I read you, it looks that a "flaw" in the video is hardly visible, so you let it go and simply display the previous data. But how will this work out on the sound? I have the impression that in sound this is very well heard, if not unacceptable?

And about the half new / half old data, I remember that in our first CD-players, read 1981 - 1983, we had this too. And that was needed because we had no fine influence of the reading of data. The CD reads as it goes and the speed servo has only low frequency influence. So the write addressing counter should never reach the read addressing counter and the other way around. The distance of the two was used as an error signal for the speed servo and was kept at 50%. At that time, 1981, we used a 16k x 1 dynamic RAM for this.

But I got the idea that reading an SD-card can be stopped and continued at will, isn't it? I hope that you can read byte by byte. Then it is easiest to have the buffer most of the time filled by 99% with "new" data. Only if the data cannot be found fast enough, due to the internal architecture of the card, you need the buffer.

And then there is a trick, for video only. Repeat the previous line when you have run out of buffer data. I don't know if you can do that easily. A sample frequency of an integer multiple of the line frequency is then needed, e.g. 32 kHz or 25.6 kHz.

[Andrew Davie]

I mocked up a quick user-interface on the Nextion just to learn how to do it - and it went pretty smoothly. All of the interaction shown here is internal to the Nextion LCD panel - the Arduino is doing nothing except supplying 5V. But the next step is pretty simple - just responding to button events from the panel. The idea is I have a bunch of screens, one for each video on the SD card. Each screen has a background image, a PLAY button, and a next/previous (not shown here). When you press PLAY you go to the controls screen which has gamma, brightness, contrast, volume, a seek control, and of course STOP. The STOP takes you back to the track selection.
Seems pretty straightforward - the next step is to get it talking to the Arduino and actually interacting. I might as well tackle the brightness first, as that's going to be fairly straightforward and easy to see if/when it's working. I don't think it will take me very long.


youtu.be/4MMYoJ_quc4