Announcement

Collapse
No announcement yet.

Christie Series 2 TPC issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by Marcel Birgelen View Post
    The NUC first needs to boot Linux and then it could auto-start the VM. Since it will now be booting on much faster hardware and from a proper SSD, it will probably still be started far earlier. If the TPC software cannot handle being "ready" before the projector is in a certain state, then you could, indeed implement an additional wait before you boot up the VM.

    It would be pretty shoddy software engineering if it fails on this, but it would certainly not be the first race condition triggered by hardware speed increase.
    Oh wait, I see... The timing worry is after the host is already on (at the time the pedestal is powered). It's the potential race condition between the booted VM (the TPC) requesting the projector to power on versus when it does it's checks. I very much doubt there will be any problem here, but even if there was, I think you could probably trigger a reboot of the virtual TPC and probably clear most things.

    Comment


    • #47
      Originally posted by Ryan Gallagher View Post
      On that virtual TPC boot time versus PIB power up timing worry. Even if there was a timing mismatch, assuming the projector was powering the virtual host in a final "polished" implementation, you could just program in a wait time before the host fires up the VM. I would assume the PIB etc is fully awake before windows XPe finishes booting on the original slow TPC. So all it's checks are to a fully powered projector.
      It does seem like as long as I don't get the specific error "PIB connection lost, please power-cycle projector" the virtual TPC will recover from a connection loss fairly quickly. As a general rule though, if the PIB is booted before the virtual TPC then things work 98% of the time every time, as the saying goes
      Last edited by Caleb Williams; 08-25-2025, 12:52 PM.

      Comment


      • #48
        The machine I'm doing testing with is a https://www.bee-link.com/products/be...i-s12-pro-n100 and is set up with the following environment:

        Debian 12 + openbox (desktop env)
        qemu-system
        qemu-utils
        bridge-utils

        I also had to download the x86 Realtek rtl8139 driver package for Windows XP, since they didn't include the original on the TPC and the driver had to be installed.

        Using qemu-utils I created an iso using "genisoimage -o rtl8139.iso -J -R rtl8139_xp/" then attached it to the vm using -cdrom rtl8139.iso. Then I used the device manager in XP and installed the the driver for the virtual nic and got basic communication working.

        I set up the networking with Marcel's configuration guide in mind. Previously the nuc was set up with dhcp, so I backed up the /etc/network/interfaces file and then replaced it with:

        auto lo
        iface lo inet loopback

        auto br0
        (4sp tab)iface br0 inet manual
        (4sp tab)bridge_ports enp1s0
        (4sp tab)bridge_stp off
        (4sp tab)bridge_fd 0

        iface enp1s0 inet manual

        Then ran "sudo ifdown -a" and "sudo ifup -a" to confirm that the br0 interface was working. I ran into an issue where br0 couldn't be configured because the primary interface was still holding onto it's config. I had to run the command "sudo ip addr flush enp1s0" to free it and then br0 was configured correclty.

        To set up the tap I ran the following commands:

        sudo ip tuntap add dev tap0 mode tap user "$USER"
        sudo ip link set tap0 master br0
        sudo ip link set tap0 down
        sudo ip link set tap0 up

        I then added the tap interface to the qemu instance using -net tap,ifname=tap0,script=no,downscript=no

        You can run openbox using the command "startx", then qemu will be able to open a window and show you what's happening on the vm. You can also interact w/ the vm using mouse and keyboard. The full qemu command is below:

        sudo qemu-system-i386 -hda tpc_t650H_ssd.qcow2 -m 2048 -display sdl,gl=off,show-cursor=on -vga std -boot c -cpu host -enable-kvm -net nic,model=rtl8139 -net tap,ifname=tap0,script=no,downscript=no -usb -device usb-tablet -cdrom rtl8139.iso

        As long as the host nic br0 does not have an ip of it's own then things seem to work seemlessly. I can control the projector from the vm as if I was in front of a real TPC using a mouse and keyboard, or even using vnc pointing to the projector's configured network address (not the 192.168.254.142). Its FAST. From pressing enter on the keyboard, it takes 27 seconds to fully boot the virtual machine. I think I need to make some changes to the qcow2 volume, or convert it back to raw, because if the vm is killed some data is definitely lost. I had two goes at installing the Realtek drivers because of that. I assume that the default treatment for qcow2 does some sort of write-caching to ram to save on the amount of writes to disk, however that is not the behavior we want if the TPC is to be treated the same a real unit. It should remember everything even on a power-loss event. I'm still working out the kinks on that, but I'm going to leave this to run and see if anything crashes over the next couple of days.

        The next step, assuming everything is stable, would be to create a systemd service that triggers the network configuration (tap) and starts the vm automatically. That will require an automatic login, automatic start of openbox, then start the vm. If for any reason the vm crashes (this can happen if a user askes the vm to restart) then systemd should restart it automatically. I'm not sure how this effects the other issue we are dealing with, which is when the automation process crashes and the projector stops responding to cues. That might require some modification of the software on the tpc to be truely seemless. I'm also not sure a constant reboot of the vm is a good idea. If you're creating a disk image to try this out yourself, don't take the disk image from a TPC with that issue.

        I've attached a few photos of the progress. Pardon the messy workbench lol

        ​​
        You do not have permission to view this gallery.
        This gallery has 4 photos.
        Last edited by Caleb Williams; 08-25-2025, 04:35 PM. Reason: Added boot time note

        Comment


        • #49
          Great work, nice to see that the conjured-up idea actually works! Happy to see that those new plans to conquer the world includes one of our feline overlords.

          Maybe you can put the gist of it on GitHub. The only tricky thing is the TPC image itself, but maybe this eventually motivates Christie to make it available for free.

          Originally posted by Caleb Williams View Post
          The next step, assuming everything is stable, would be to create a systemd service that triggers the network configuration (tap) and starts the vm automatically. That will require an automatic login, automatic start of openbox, then start the vm. If for any reason the vm crashes (this can happen if a user askes the vm to restart) then systemd should restart it automatically.
          I think you can do most of it if not all via /etc/network/interfaces, here is an example.

          Comment


          • #50
            Apologies if this thread has gone a bit away from the original topic

            Turns out there is a way to get qemu to set up the tap interface without all of the extra commands when it starts. I'm going to try testing that method for simplicity. So far the virtual TPC has been rock solid after 24 hours. I did run into an initial problem where when I would try to vnc into it and tvnserver.exe would crash. I think I had something weird going on with the bridge, because I was also getting duplicate ping responses. After a reboot and a fresh start with all of the commands listed above it hasn't done that again. Even if tvnserver.exe crashes the "vTPC" stays connected with the PIB and you can still control things directly with a keyboard and mouse. If that's the only weird quirk then I'll be quite happy with the outcome.

            Is github a good place for a guide on this? I could also create a new thread here. I'd like to include a TPC image on 4.8.1.3, but would also include instructions to make one yourself. Also, at a sub ~$200 price-point, I'm not sure it's worth exploring the ability to emulate multiple TPC's on the same machine. Creating a virtual VLAN environment and keeping traffic organized for more than 3 "vTPC"'s would be a challenge I'm not sure is worth the payoff, (including from the additional network hardware overhead).


            Originally posted by Marcel Birgelen View Post
            Gen1 TPCs run on Windows CE, which is not really a traditional Windows, as it uses a different kernel architecture. Gen 2 TPCs run on Windows XP Embedded, which is essentially a dressed down version of Windows XP.

            Correction: Gen1 is an ARM Based system and Gen2 is an Intel x86-based AMD Geode system.

            I think it will be easier to customize an XPe image than a CE image.


            Were Gen1 TPC's on series 1's like the CP2000SB? qemu is a very versatile emulator, and I'd bet we could do gen1 if there was any demand for it. Otherwise, I'll stick with XPe. I've got a pretty good idea of how to automate the launching of the vm based on some scripting we've done for our in-house media player project. If everyone is happy with github I'll get started on a formal guide. If there are enough adopters then I can make time to design a simple electrical system to power the "vTPC" off the projector standby supply, and maybe a 3d modeled housing for it, but byo-touch panel. An easy touch panel might be similar to the display used on the series 3, but I know those are a bit expensive. I could easily see this as a stand-in or rescue system to get back on screen quickly while waiting for a part to be delivered.
            Last edited by Caleb Williams; Yesterday, 12:29 AM.

            Comment


            • #51
              I think a separate thread here is certainly justified. As things get more polished a place to host the project like github is good.

              Someone else who wants the multiple VMs functionality can pick up where you left off. Just having cheap a 1:1 hardware replacement option for a bad TPC seems like a win. Techs would be hella confused if they started encountering "brainless" projectors out in the wild with all the TPCs virtualized in a rack somewhere. But for plexes I do see the economy of scale appeal.

              Is there still an option to consider the RasPad? Will qemu work the same emulating XPe on an arm system? Or does that require another layer of emulation? Maybe one could just try it on a regular Pi before spending the $$ on a RasPad.

              Comment


              • #52
                Originally posted by Ryan Gallagher View Post
                I think a separate thread here is certainly justified. As things get more polished a place to host the project like github is good.

                Someone else who wants the multiple VMs functionality can pick up where you left off. Just having cheap a 1:1 hardware replacement option for a bad TPC seems like a win. Techs would be hella confused if they started encountering "brainless" projectors out in the wild with all the TPCs virtualized in a rack somewhere. But for plexes I do see the economy of scale appeal.

                Is there still an option to consider the RasPad? Will qemu work the same emulating XPe on an arm system? Or does that require another layer of emulation? Maybe one could just try it on a regular Pi before spending the $$ on a RasPad.
                I'll be honest, I'm not sure the pi4 has the juice to make x86 emulation happen. I think the pi5 would be a better option, but we're getting really close to a solid used NUC price on those even without the power brick and display adapter. The RasPad is listed at $218 and it is only available with a pi 4 at the moment. They are also sold out, so they might have less availability than an OEM TPC (lol what). I still want to try a pi 4 just to see what would happen.

                It actually wouldn't be that difficult to run all of a booth's projectors on the same virtual machine host, but yeah you'd get really into the weeds with networking, bridges and VLAN's specifically, and someone not familiar with that level of networking would struggle to figure out what the heck was going on. I imagine the scene would play out like when the Star Trek crew had its first encounter with the borg.

                Comment


                • #53
                  Originally posted by Caleb Williams View Post

                  I'll be honest, I'm not sure the pi4 has the juice to make x86 emulation happen. I think the pi5 would be a better option, but we're getting really close to a solid used NUC price on those even without the power brick and display adapter. The RasPad is listed at $218 and it is only available with a pi 4 at the moment. They are also sold out, so they might have less availability than an OEM TPC (lol what). I still want to try a pi 4 just to see what would happen.

                  It actually wouldn't be that difficult to run all of a booth's projectors on the same virtual machine host, but yeah you'd get really into the weeds with networking, bridges and VLAN's specifically, and someone not familiar with that level of networking would struggle to figure out what the heck was going on. I imagine the scene would play out like when the Star Trek crew had its first encounter with the borg.
                  Haha the Star Trek scene indeed. FYI RasPad's are not sold out on Amazon. But yeah, 399$ is steep... depends on how bad you need a touch panel and if alternatives are economical. I bet people have stuffed Pi 5s into them already though.

                  On the more economical front, with probably a lesser quality display... are the plethora of things like this touch panel case (supporting 3, 4 and 5):
                  https://www.pishop.us/product/smarti...h-pro-3-large/

                  A Pi5 8gb plus that thing only set you back about 110$?

                  Comment

                  Working...
                  X