Is this application possible? RPI4, web interface, RS232

[KeepItSimpleStupid]

I used Labview back in the v2.2.1 days and further out in an academic research environment.  Scratching my head I don't know what to believe.  Stuff right now seems very disorganized to the point that no one knows what's up.

#1.  I need two virtual COM port interfaces for two devices external to a RPi4B.

#2. the RPI4 will be headless behind the TV,

#3. What it has to do initially is to keep tabs on a dual AM/FM tuner that can be controlled via RS232 or IR.

#4. it should display what it finds from the tuner as though it's connected to a vt100 type of terminal 25 lines x 80c via a virtual COM port on the PI.

#5. The tuner interface allows unsolicited messages, so in theory it  should be able to

detect key presses.

#6. For the most part, the vt100 portion might show

    FM 101.1 P6

      WSUX

  Dreams - Fleetwood Mac

It will use direct cursor addressing to do that,

So, pretend it's a vt100 terminal that's controlled by the PI using a labview application.

it isn't, but it's a close enough description.

Display wise it might move that info around the screen or it might appear for a certain length of time and fade away with the cursor hidden.  P6 might be preset 6.  I don;t know.

the IR remote would be transmitted to the tuner and the tuner RS232 will pick up that information and display it.

So, basically, there should be a hidden VI that emulates a vt100 and there is a "real vt100" nearby.   There isn't, but that's OK.  The vi and the terminal should appear the same.  Makes it easier to debug.

Simplistically its a display for an IR remote control using the RS232 interface of the tuner.

To complicate matters, there are two tuners and one RS232 interface controls both.  One will be primarily controlled with the IR remote.  The other, I'd like to have a web interface most of the time.

So, if you do this linx rasberry Pi voodoo, do you really have a UI that runs on the PI?

I'm beginning to think the answer is no?

The PI would be running headless, but the UI should be accessible from a webpage,

You could easily convert vi's from programs to webpages and I hope that would work?

So, now I have an dual AM/FM tuner that can be controlled via an IR remote or a webpage and visible on the webpage in some manner and visible on this vt100 thing.

i.e. I could change the station via a webpage on my phone or the IR remote control.

Somehow, LabView runtime on a Rasberry pi has way to many limitations.

Otherwise, I may have to try to use Python and I don't know Python.

The first hurdle software wise is:

Get a PC

Get the virtual com ports to work

Interrogate the tuner

Display on this vt100 port.

Everytime I visit, nothing seems to work.  Much like LV 2.2.1 and LV3.  I don't remember the last version  I used.  i think Digilent gave up too.

So, I need:

Two Virtual COM ports on the Rasberry PI.

I need to be able to convert the VI to run as a web interface on the headless Rasberry PI of the Labview vi.

The project has the potential to morph into other things.

#1.  Real time Antenna position display via an accelerometer (web only)

#2.   Control a TV via the HDMI-CEC bus and an adapter from pulse-eight

There is a linux library for that device.

The TV needs to be auto-muted for things like:

a) doorbell/knock

b) Phone rings

c) Phone goes off hook

d) Nurse call gets activated.

other areas could include drapery control, access control, and video doorbell and a custom simplified IR remote.

There's missing stuff, but enough to get started.

[rolfk]

To be honest, this whole post sounds like a disorganized brain dump of some sorts. By reading it I got the impression to have read some things already two or three times earlier, others are kind of stuck in terminology, such as about VT100 terminals and such which make very little sense unless you have a monitor (or PC application) that can understand VT100 (which is so 1970). Then you talk about webpages as alternative UI which is pretty much the opposite of VT100. So which of the two should it be? Neither is point and click for sure!

I think you need to first organize your requirements by categorizing what hardware you really have and how you want to communicate with it. The problem is not that LabVIEW, the Raspberry Pi or whatever can't do these things, but that your requirements are fuzzy, unorganized and chaotic. There are indeed AM/FM receivers with RS-232 or similar interface, quite often through some non-standard DIN connector with non-standard proprietary pinout. The interfaces are generally meant to be used with the same manufacturers other devices to interconnect them. That was before everything was connected through HDMI and similar interfaces that integrate Video, Audio and TCP/IP and whatever in the cable too. Those serial port connectors were seldom real standard RS-232 or RS-485, but rather some proprietary variant of it, the protocol used was hard to impossible to get documents for and the whole was generally badly designed to work as vendor independent interconnect.

And yes, the Raspberry Pi if used as LabVIEW deployment target is headless. The Debian Linux chroot virtual machine inside the Raspbian host OS, that executes the LabVIEW runtime environment is a separate virtual computer that has not really access to the video interface of the Raspbian host OS. You have to somehow communicate with an external display. This could be a network connection to an application running on the Raspbian host, a separate LCD display connected to the I2C interface of the Raspi or a serial port to a computer that runs some terminal emulation software.

If this all sounds complicated, it's because it is complicated. You are trying to integrate several different hardware components into a single system, that were never designed to communicate together with the typical point and click installer experience that many have come to expect nowadays. Instead you will have to get your hands dirty, solder cables and interface breadboards, and tinker numerous hours to get all the different things to talk properly together. LabVIEW doesn't really make it more difficult than other solutions would. The main difference is just that LabVIEW is a more niche ecosystem than when you compare it to Python nowadays. But if you find Python libraries that will work with your specific hardware is just as questionable and even if you do, if they will work is an even bigger question. There are really great Python projects out there, developed and maintained by real wizards. But just as much if not more out there was hacked together by hobbyist with the typical approach of "Look mom, I can cycle without hands!". But don't try to look to close or the whole thing breaks into pieces at the slightest breeze.

[KeepItSimpleStupid]

Rolf:

The RS232 protocol: https://media.distributordatasolutions.com/legrand/2019q4/4c243439fc2f973dd0fe86d94e5b387cc34f309a.p... to control a tuner.

The Vt132: https://thehighnibble.com/vt132/#overview

it's basically a built from scratch system that emulates a vt100, uses a PS/2 or USB keyboard and it has VGA output.

Currently, I have connected a VGA test generator to a VGA to HDMI converter and then a HDMI cross-converter to a wireless HDMI transmitter.

All of this means, I can transmit audio to the HDMI input with a stupid test pattern on it.

So, I want to be able to control a tuner with IR and RS232 and display that information the TV through a RS232 -> vt132 ->VGA ->HDMI interface.

So, I can at this point listen to an audio source on a smart TV on the smart TV, with a "test pattern" present.

The Vt132 will replace the test pattern.  If I turn off the cursor, in theory, I'll have a black test pattern.  I have not played with the brightness and contrast controls on the converters.

I should be able then to write on the  TV as if it was a display of a vt100 terminal.  The vt132 kit is not put together.

So, like I said:

#1: Two virtual COM ports on the rasberry PI (Likely possible, re-compile kernal)

#2. A console server to get me two RS232 ports at the tuner/vt132 (liklely possible)

#3. A Rasberry PI4B will exist at the TV connected wirelessly first. (not there yet)

the PI will be headless and typically accessed via VNC or SSH.  (this seems possible)

Now, the Labview questions:

Can I get a webpage from a Labview vi running on the Rasberry PI that I could use on a laptop or a phone?

LabView needs to access the two serial ports as virtual com ports.

The main purpose of the project is to be able to listen to an AM/FM tuner through a Smart TV without buying an AV Receiver.  Tuning of the tuner should be possible using the IR remote AND a LabView web interface.  

Can This be done using LabView and a Rasberry PI?

I want to hit keys on the IR remote and see activity on the V screen after selecting the appropriate HDMI input for the tuner.  The TV becomes the display for the tuner.

I also want to be able to control the TV via a webpage as well,  With the full version of LabVIEW, you could turn stand-alone applications into a webpage.

I don't think LabVIEW can do this?  Thus I may be stuck with Python?

The PI is the platform of choice, because I want to use this https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter  as well, but not for the tuner/TV project.  There are Linux libraries to control this adapter.

I told you what I needed to accomplish without including all of the details.

#1. Dual tuner interface/display on a smart TV

        "keyboard" is IR remote or Web Page

#2. Control of the TV using HDMI-CEC

        I primarily want control of "MUTE"

#3. I may want to display on a webpage the real-time compass angle using an accelerometer mounted on the TV antenna.  There is a home made rotator design on the Web, that includes such an accelerometer.  

My antenna rotor uses DiSeq/C over coax.  The final position is very accurate.   The position while it's moving is not.

I can currently control the rotor "blind" with an IR to RF to IR repeater.  I have no idea where it is and where it's going.  If I'm at the display, the display is wrong when the rotator is moving.

Rolf: You need to say your sorry.

My original intention was to use a 4-channel ATSC/IPTV modulator, but I still had to come up with a black raster HDMI source with audio.  This is what I really wanted. 

I've created a simplification.

Using a Barrix Instreamer/Extreamer is yet another way to do audio.  I can add an Extreamer and be able to listen to an audio stream on my laptop.

I really wanted both radio and TV.  The modulator requires HDMI only and I need Gigabit Ethernet.  I would be able to listen to audio by just changing the TV channel. I'd be able to tune the TV tuner with a Web enabled tuner (I have one) and watch it on a laptop.

So one channel would be TV tuner, the other AM/FM tuner 1 and AM/FM tuner 2. 

You would also get IPTV streams.

ATSC-3 is on the horizon.

[DavidWilt]

---

Now, the Labview questions:

Can I get a webpage from a Labview vi running on the Rasberry PI that I could use on a laptop or a phone?

---

If you are using the LabVIEW Community Edition it includes the NXG Web Module which can be used to create code which runs in any web browser.  You can use the NXG Web Module code to interact with the LabVIEW code running on the Raspberry Pi.  Here is a link to a presentation that I gave on this subject.

---

With the full version of LabVIEW, you could turn stand-alone applications into a webpage.

I believe you are referring to Remote Front Panel which has been around for a long time but is not supported by the modern browser.  I would recommend using the NXG Web Module.

[rolfk]

Sorry, about 70% of the terms you throw around with mean pretty much "Bahnhof" to me.

What I do know though:

Yes you can of course generate HTML code on a Raspberry Pi with LabVIEW. The low level way is to implement your own HTTP server in LabVIEW on top of the TCP/IP nodes and generate the HTML format in LabVIEW as well. I have done such things back in 1995 😀.

Nowadays however you simply run an instance of Apache HTTP server and feed it some html, php or similar and let it handle all the rest.

What are the virtual comm ports for on the Raspberry Pi? Do you intend to use external USB-RS-232 converters to connect to your VT132 and Tuner device? Why? The Raspberry Pi has UARTs on the extension connector that can be connected more or less directly (well they are not really RS-232 but rather 3.3 V HCMOS level uarts that are 5V tolerant. If you need real RS-232 logic levels you would need to add some level converters in between. On the other hand if you really want to use USB-RS232 converters and don't choose some super duper cheepy chinese fake devices, they will generally be detected and found by the Raspbian OS automatically at startup and installed in the /dev tree as some tty device. From there NI-VISA is fully capable to pick them up and present them to you as standard ASRLx resoruce and you should be able to access them from your LabVIEW VIs just as under Windows.

The Linx library as implemented now, will however only know about the standard uart interfaces that are always present, and doesn't support access to other uarts without recompiling the liblinxdevice shared library.

IR interfacing I haven't done. My old knowledge about IR control is that there are several coding standards and most manufacturers tend to use their own. The principle of an IR remote control is in theory quite simple as you just need to pulse an IR diode in the right frequency pattern, in practice it is quite complicated as bit banging that pattern is fraught with trouble since you are not running on an old DOS computer where your assembly code will run as only task so that your assembly coding can be timed to create the correct pattern. Instead your software runs on a multitasking, multithreading OS and the timing constraints are such that you can't hope to have guaranteed software timed routines that will always generate the right frequency pattern. Maybe the current state of IR control is different but back in those days, things like RC4 and RC5 were quite common and that was not a protocol that you could directly connect to an RS-232 port and hope that the uart will decode it.

[KeepItSimpleStupid]

NI put a muzzle on me. Two posts in 24 hrs.  But it looks as if I can compose something.  As usual, the message "As a new user, you can only post twice in the first 24 hours. "  Is not helpful.  They need to add "you may post after day of the week xx:xx"

I'd like to deal with things in pieces without a lot of information in one post.

The PI 4B 8 gb was purchased used. It needs to be put into a case, powered, and have VNC installed and SSH access.  It may need a HDMI gizmo so it will operate without a monitor attached.  My version of headless.  No monitor. No keyboard,  Access via ssh and VNC.

For later use, the pulse-eight interface needs to be connected in series with an HDMI cable. It also needs USB from the PI or a USB Hub.

I probably could connect the PI to the TV HDMI input and use the wireless keyboard I occasionally use for the TV.  It has a large KB and a trackpad from Logitec.

[quote]

What are the virtual comm ports for on the Raspberry Pi? Do you intend to use external USB-RS-232 converters to connect to your VT132 and Tuner device? Why? [/quote]

No BBCODE - Yuk!

The kernal will have to re-compiled to add the virtual COM ports.

The virtual com port would come from here:  https://www.perle.com/supportfiles/trueport.shtml

They would be standard /dev/tty or a pty.  I might even try socat.

The set-up:

The TV is in a hallway.  It's a 55" Samsung Smart TV which is really dumb. 

e.g.

Scan and add channels is not possible.

Using only audio from an A/V CVBS input or HDMI input is not possible.

It looses closed-captioning - to reset you have to unplug the TV

Youtube sometimes has a Chinese menu whenever it feels like it.

 I can't use a QWERTY keyboard to search using characters on the keypad.  I have to use the arrows and select the characters from a list.

It doesn't do automatic daylight Savings Time correctly.

The remote control is some mix of IR and bluetooth,

I can't turn the TV on or off using the keyboard.

So, a stupid 55" Samsung System 6 TV

It's difficult to fish wires to the TV.  There is a CAT3 telco interface which I am using and two RG6 TV cables to two televisions.  One faces the kitchen.  The other is the "Smart TV".  The TV uses wireless internet.

The old TV had a speakerphone built into it.  Now, the telco socket has a device that lblinks a LED when the phone rings and the LED is steady when the phone is off hook.

The LED is placed in the middle of the TV.  It can check voice male too.

So, the TV is connected to wireless Ethernet and it doesn't like multiple SSID's of the same name.

The PI should be able to connect to wireless Ethernet.

So, there would be the following devices where the TV is:

#1: The TV

#2: The wireless HDMI receiver and power supply. (works)

#3. An IR receiver that plugs into #2 (no extra charge)

#4. The Rasberry PI, power supply and case.

#5. The pulse-eight CEC-HDMI adapter via HDMI and USB.

future: Access to interfaces that don't exist yet.

a) the front or rear doorbell rings

b) Someone decides to use the knocker and not the doorbell on the front door.

c) Nurse-call gets activated

d) Doorbell camera gets activated (One doesn't exist)

These events need to mute the TV. 

Unmute is a manual thing (i.e. use the TV remote)

Doorbell cam activated, should display on the TV.

The CEC-HDMI can help with that, I think.

Options that could happen:

Talk to the visitor at the door

Unlock the door.

Open/close the vertical Blinds.

yep, would like an "access control system" that's more complex than your used to.

Here, we are designing the ultimate and making what we need,

Putting a thinking cap on, I could leave a message on the TV or something.

Lots of stuff is possible.  e.g. Reminder to take insulin/medcations.

Once I have a few pieces in place, I can think up other functions.

A: I want an AM/FM tuner to be able to play through the TV speakers.

B: I want to automatically be able to mute the TV/radio by events.

C: A doorbell event, might switch on the TV and send a video feed there.

I do envision her talking to someone at the door, unlocking the door and letting them in with a remote control.

Msybe Alexa will show up.  My mom is confined to bed, she was in hospice.  She hasn;t use a computer or a cell phone.

She likes "push this button" and "Y" happens EVERYTIME.

In development by a friend is a unique IR remote control that I could incorporate.

The barix instreamer'extreamer https://www.markertek.com/product/barix-instreambs/barix-instreamer-multiprotocol-audio-over-ip-enco...  offered some unique capabilities.

Then finally there is an option to use HDMI & IR over CAT6 for the audio over the Samsung issue and use an Extreamer for audio to a laptop.

These devices open up other ASoptions

[KeepItSimpleStupid]

See below:

It really looks like NI is abandoning their established base  (e.g. Digilent, a NI subsidiary or whatever) until they can get their head on straight.  It would be like back in the days of LV 2.2.1 only with no "compatability VI's"

A key concept of web operabilty was totally unheard of?

Way too many changes (2020 onward) are being introduced at the same time.  I think this may spell disaster.

I don't think Digilent was very happy. I get the impression, that if you want support for the Hobbyest/Community or whatever the flavor of the month is edition,now you have to goto to NI.  They pulled the rug out from under Digilent.  NI and Digelent have totally different models of operation,

The Rasberry PI might be able to run LabView including the front panel structures.  Maybe that's what it should do in the interrim.  Long-term, Labview could become  a client-server version where some or all front panels run as a webpage.

Maybe start and make some front panel controls, client-server.

What I remember most about the LV 2.2.1+ days is indicators flickered.  You had to re-write your code differently so they didn't.

To the NI Community,

Software is a critical differentiator for NI. But software at NI doesn’t represent just a set of products that contribute to our offerings. Our software portfolio connects our entire platform and provides capabilities that set our solutions apart.  

LabVIEW is a vital part of our expanding software portfolio. To build on the success of LabVIEW, we developed the NXG Platform which has enabled an entirely new set of offerings such as the NXG Web Module, SystemDesigner, FlexLogger, InstrumentStudio, VeriStand, and Digital Pattern Editor. You’ve told us there’s tremendous value in these NXG-based solutions, and we agree.  

We also built a new product, LabVIEW NXG, based on the NXG Platform. While your feedback has been positive and there’s been excitement about what you’re seeing in LabVIEW NXG, you’ve also shared with us some of your concerns around migrating to an entirely new LabVIEW product. And although we’ve mitigated some of these issues, we agree and want to empower you to focus on addressing your future test and measurement needs. 

That’s why we’ve decided to take the following steps: 

1. We will integrate the strengths of the NXG platform into our LabVIEW 2021(+) codebase, which will result in the best of both worlds. This means centralizing our investments in LabVIEW in a way that enables us to deliver even more value to LabVIEW users in the years ahead. 
2. We will continue to advance our NXG-based portfolio of solutions such as the NXG Web Module, SystemDesigner, as well as our expanding suite of configuration-based products such as FlexLogger and VeriStand. As part of this commitment, you can expect to see the NXG Web Module and SystemDesigner integrated into other parts of our portfolio.   
3. We will cease development efforts on LabVIEW NXG and release the final version - LabVIEW NXG 5.1 – in 2021. We will not release new versions of LabVIEW NXG starting in 2022.  

Our teams are working on these projects today as well as the significant new investments we’re making across our entire software portfolio, including in Product Analytics and Test Operations. Collectively, our ongoing investments in this well-rounded portfolio give us a unique ability to create a digital thread that follows a product across the development flow and through its entire lifecycle. This allows us to provide new value to you at an even larger scale - like reducing overall time to market, significantly lowering operational costs and helping you address pervasive product and performance issues before they impact your customers.   

The steps we’re sharing today – the long-term commitment we are making to LabVIEW as well as our ongoing investments in configuration-based software, Product Analytics and Test Operations – will bolster our software capabilities and better support you. They are aligned to our software strategy and our commitment to providing all of our customers and partners with the most innovative and powerful software in the Test and Measurement industry. 

Thanks,
Omid Sojoodi, VP of Software R&D
Stefanie Breyer, VP of Product Planning