Pod Electronics

This should contain a bit more details about the electronic components of the hyper loop pod.

• Lighting Internal - white LEDs for sure... - normal level: guess 500? lumen/psgr (passenger), at 50 lumens/watt -> 10 watts/psgr - each passenger's zone dimmable at their seat - emergency level: can be lower, 50? lumen/psgr -> 1 watt/psgr - anybody know the standard illumination levels, i.e., for airliners? (It's probably in lux or lumen/sq meter, not just lumen...)

• Fan

  • mass, power, rotary momentum and kinectic energy...
  • motor design...

• Fan controller

  • some kilowatts...

• Airspeed sensor?

  • airspeed sensor, and also wallspeed sensor
  • wallspeed is the real speed, airspeed consists of 2 pressure sensors, one fore and one aft, to measure air pile-up, i.e., the effectiveness of compressor functioning, or during emergency stopping the present degree of air-braking effect

• Sensors

  • pressure front, pressure rear, wallspeed, acceleration 3-axis, turning rates 3-axis, flux/thrust level at linear motor susceptors, ...
  • temperatures: many: air in front, air in rear (exhaust), compressor 1 outlet, compressor 2 outlet, batteries, passengers, side-skin n? places
  • relevant to human passengers: accel 3-axis, gyro 3-axis (I would skip the gyro since they are prone to drifting and just stick with the accelerometer (OpenHyperloop)), internal air pressure, temperature, O2 percent, Carbon Monoxide, smoke, acid vapors, humidity, organic odor level, light level and light flicker level, sound level, motion level sensor for bodies inside capsule,
  • for evacuation should probably have external air pressure & temperature sensors, with displays visible to all passengers
  • I think it would be cool to give passengers access to a page showing wide variety of sensor data at their display, and options (almost a programming language) to combine them into a subliminal background sound of their choosing.
  • to assure clear tube: down-tube sonar? frequency-sweeping waveguide reflectometer? Cameras, easily, but only until curve-horizon... Most of these would not actually provide enough advanced notice to stop in time, but they'd be reassuring, see occasional minor debris or whatever, and provide clues in case of a crash.

• Battery

  • cooling & gas-control structures, for both normal and burning conditions
  • mass, volume of batteries

• Battery controller

  • some kilowatts
  • mass of controller, power-carrying cables
  • volume of

• A way to communicate with stations along the pods to relay information about the pod location, status etc.

  • Radio:

    • patch antennas for 2.5 or 5 GHz would require only 1/8-inch round hole drilled thru tube wall
      • perhaps these should be recessed into wall, requiring a 2-inch countersink tool
    • better to have an antenna which projects longitudinally along axis of tube. It will be a multi-mode waveguide, link-strength not very stable...
    • perhaps radio should be at the frequency of a fundamental-mode of the tube as a waveguide
      • This is an interesting idea, but with an internal diameter around 10-11', the frequency would have to be very low and that frequency is probably already licensed to someone. (OpenHyperloop)
    • range estimates...
    • distance detection from signal... transponders, signal-strength at straddling antenna-stations...
    • tube-radar to measure capsule position between antenna-stations ?
    • There should probably be more constant communication between the tube and the pod. The main central monitoring system for the Hyperloop should be able to see the status in each pod, so I think every section of tube about every 50-100' would have an antenna and radio stream back to the main NOC so they are aware of the status of every pod. The tube will have fiber optic cables running along them so they can easily transmit the data back to home base. (OpenHyperloop)
      • FWIW, I've setup a Hyperloop Protocols page to start talking about what sort of software communication protocols and signals will need to be sent between pods, tubes, and central stations.

  • Optical:

    • probably IR laser 1? W with 50? MHz subcarrier modulation

    • data-rate lower for good range... what's adequate data-rate?
      sensor data packet 1 Kbyte = 10 kBit, every 10 millisec -> 1 MBaud

    • line-of-sight: won't transmit around curves much

      • horizon distance for tightest allowable curve: ...

    • stations on tube-wall might be very small, so, very minimal disruption of tube wall

  • near-field induction to a wall-embedded cable running large length: ...

    • dilemma: cut long groove, or cope with minimized protrusion ...

• Way to charge the battery. (induction?, maybe battery pack swap at the station?)

  • direct contacts

    • only when out-of-service, out-of-tube, docked in station
      • manually connected vs. automated ?

  • induction

    • only when docked in station
    • also en-route in tube
      • kHz AC field from coils
      • static DC field, capsule passing at high velocity causes pulse effect in pickup coils, (probably can't afford to do it with Neodymium magnets...),
        the charging energy in effect being supplied by the propulsion linear motors
    • Elon's Alpha doc estimates that pods are cheap, so extra pods could give more time for recharge while docked at service station at endpoints, thus creating an extra channel for carrying energy into the tube to do the high-power job of propulsion...

  • induction pickup coils are most effective or technically easiest when close to the driving coils. i.e., close to the tube wall

  • a surface already close to the wall is the lift-foot, Also perhaps a linear motor susceptor foot

  • how to get transmission thru thick steel tube-wall?

    • tubes with section cut out and patched with other materials (insulator & coil...)
    • for DC field: slot cuts thru tube, patched with anything non-magnetic, sturdy, cheap.
    • wall-embedded cable or ribbon(s) running down tube...

  • how about a battery pack swap while at a station? similar to a fast-swapping battery packs for electric cars? (OpenHyperloop)

• Passenger display system

  • media streaming
  • sensors display
  • communication
    • minimum: IM w. system operator & other passengers; IM-to-{text, e-mail, twitter).
    • more: general internet service? what download rate? cell-phone link?)
      • this would be ideal, providing inet/cell/4g services on the Hyperloop was my vision. Fortunately, running along existing interstates shouldn't pose a problem for that since companies already build their antennas along those highways already (OpenHyperloop)
  • I flew Virgin Airlines once a few years ago; this display system would be similar to theirs, I hope just a little better...
  • programmability: I think it would be cool to give passengers access to a page showing wide variety of sensor data at their display, and options (almost a programming language) to combine them into a subliminal background sound of their choosing. Also demure alarm-sounds settable at locations or progress intervals...
  • bluetooth or wi-fi to enable using passenger-owned equipment as display...

• Whole-cabin audio intercom w. system operator, under control of system operator & automation.

Comment: I seem to be stepping on this page pretty hard, and I haven't even done any real number-work yet.
I'm enthusiastic but I don't want to be obnoxious. I'm new to github. What's the protocol to negotiate such things?
Should I try forking this wiki? Tell me when... (jimswen)

Jim, Keep going! This is exactly the sort of info and data we need on this wiki. Personally, I love this page, and I will spend some time on here. I think we should break down each of the sensors and figure out ideas of costs and electronics for them. The Pod electronics need to be solid and make sure that there is also safety built in as well. (OpenHyperloop)