You have likely thought this through, but thinking about my days at university, hearing the audio only without seeing the equations and notes o= n the board would make it almost useless. Maybe OK for artsy type courses, but not math/science based. Gordon Williams ----- Original Message -----=20 From: "V G" To: "PICLIST" Sent: Tuesday, September 18, 2012 10:38 AM Subject: [EE] Major project, advice on the implementation specifics > Hi all, > > I have created, am the owner of, and have been planning a major project > with my university for automatic lecture recording. I'm surprised that U of > T, the largest Canadian university is so behind in terms of mass practica= l > applications of technology. The entire project will be completely open > source, non profit, and university (student) run. > > I'm seeking advice from you guys with respect to the hardware > implementation of the system. > > Currently, lecturers use a radio microphone link that transmits audio fro= m > a small microphone and transmitter attached to their body to the podium, > where the audio is received (I assume via a standard 3.5mm jack) and sent > to the speaker system for amplification. > > My design aims to be as non-intrusive, simple, reliable, and compatible, > and cost-effective as possible. I proposed (but can be changed) a small > device (computer) which taps into that analog audio signal at the podium > (like a T splitter) and records that audio, which is then later made > available to students for download. > > 1. The first major component of the field hardware is the computer module= .. > Timing of the availability of the Raspberry Pi is perfect for this > application. If I can manage to order about ~200-300 Raspberry Pi units > initially, I can start the implementation right away. If not, I have been > considering small, rugged plug computer that I've been keeping an eye on > for the past year or so. Comments/suggestions on this would be appreciated. > The computer module should have ideally: analog audio ports for signal > input (like mic and line in jacks), USB ports, provisions for > ethernet/wifi, provisions for attaching a small touch display, enough > processing power for real time audio recording, AND video recording in th= e > future. So far, the Raspberry Pi seems to be perfect for this application= , > but I don't know if can get 200+ units by next semester (January). At the > very least, I should get a (incomplete, not fully cased) proof of concept > up and running in at least 10 rooms before the start of next semester. > > 2. The second major component of the filed hardware is the analog > electronics used for tapping into/splitting the audio signal from the > receiver (which normally goes to the speaker system for amplification). I > need to make or find an off-the-shelf unit for this purpose. Requirements= : > - It doesn't *have* to be in a single unit. The functionality can be spread > out to two units, for example, if you guys suggest that it would be a > better way to go. > - Active splitter with manual +/- gain adjustment, for example: a small > knob that can be turned if needed to increase/decrease volume. > - One or more inputs and two or more outputs. One output will be connecte= d > to the lecture room's speaker system, and the other output will be > connected to the computer module for processing and recording. > - Should have parallel sockets on all inputs and outputs for various type= s > of audio jacks so it's compatible with whatever common audio equipment th= e > professor/university uses. I need to go and survey the different types of > jacks being used at the moment. > - Should to be able to control the splitter module from the computer > module. The computer module needs to be able to turn the splitter on/off. > Not sure if this is an important requirement though. > - Should be reasonably priced. > - Not all lecture rooms/professors are equipped with microphones, > especially in the smaller rooms, so I will need to set up independent > microphones in those rooms. It might be a good idea to specify that the > unit include the appropriate mic inputs and biasing for external > microphones, as well as "phantom power" used in studio recording > microphones, if such a mic is used. This functionality can be in a separate > unit - probably a good idea to have it separate from the splitter unit > anyway. > > I'm really quite unsure about the best way to go here, with respect to th= e > splitter unit. Is anyone aware of a unit that can do the above? Or would = I > need to design my own? (I don't mind). > > 3. The interface that the lecturer uses at the podium should be super eas= y > to use and simple in design. Should also be rugged, to withstand angry > professors mashing away at it. I'm thinking of using a normal (non-touch) > LCD screen behind glass, with a USB (numeric) keypad used to control the > device. This can always be changed as necessary. > > 4. The device should be well electrically shielded from audio interferenc= e > and shielded from physical damage. The casing should hold the computer > module, power supply, and splitter module. > - Solid (metal?) case, with mounting holes to bolt it to the podium if > necessary. > - Obviously, must expose the appropriate ports. The USB WiFi module will > probably need to be as exposed as possible. > - Needs to have a glass/plastic transparent panel over the small LCD screen > to prevent damage to the display. > > It will most likely need to be custom designed, but I don't plan to do it > myself as I don't know anything about 3D design. No idea where to start. > Any suggestions? > > The whole unit will be braindead-simple to install for the engineering kids > I'm going to assign the installation task to. Carry unit to podium, plug > into power outlet, connect speaker system to the unit, power on, and > proceed to the next room. The professors then simply plug in their mic > output into the unit and everything else is taken care of by the unit. > Simple as that. > > The unit will be on continuously, and be recording for 12 hours a day. At > night, it will perform the required automatic audio post-procesing before > uploading the finalized audio file to the file server. This is why the > reliability of the analog components is essential. The analog part needs to > be working at all times. Eventually, hot standby functionality will be > added to the system to switch over to a secondary unit in case of failure. > > These are just preliminary specs for the hardware unit. Obviously, I need > to spend a lot of time thinking this part through as I want to build this > unit to last many years. I'm unsure about a lot of it, which is why any > tips/suggestions/comments about anything at all from you guys is highly > appreciated. > --=20 > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .