**** BEGIN LOGGING AT Sat Mar 03 02:59:59 2012 Mar 03 06:59:15 The hardware is probably too different between both devices Mar 03 10:19:06 hello , installing maemo , gives that error x86_64 : http://bitsy.me/img4dy - WTF? Mar 03 10:50:29 installing maemo? Mar 03 11:06:01 this is a troll, he posts this in many channels. Mar 03 15:36:54 hi guys, is there a way to make the front camera change permanent ? Mar 03 15:36:57 gst-launch-0.10 v4l2camsrc device=/dev/video1 driver-name=omap3cam ! ffmpegcolorspace ! videobalance brightness=0.5 contrast=1.2 ! autovideosink Mar 03 15:37:04 resets itself back to default on each boot Mar 03 15:44:58 LinuxCode: well, but it in some startup-script? Mar 03 15:52:23 then it will start the cmaera each time Mar 03 15:52:26 there must be a bgetter Mar 03 15:52:29 way Mar 03 15:53:38 find where the normal command to run the camers is defined and change it accordingly? Mar 03 16:08:55 those settings are great LinuxCode :) Mar 03 16:09:14 Sicelo, in what sense ? Mar 03 16:10:19 fixing thee useless dark front cam ? yeah Mar 03 16:10:22 hehe Mar 03 16:10:32 with all the ones i tried, i was still pitch black on front cam (well, i'm black to start with - but not pitch black, lol) Mar 03 16:10:46 yeh Mar 03 16:10:55 that they never fixed that is a disgrace Mar 03 16:11:16 but then people keep saying the skype setting works Mar 03 16:11:33 it lacks an app to set brightness Mar 03 16:11:36 and contrast Mar 03 16:15:54 * Sicelo hasn't used skype much Mar 03 16:49:02 "...The CPU, in particular, appears to have more connected pins than there are actual sockets." Mar 03 19:47:58 Hi ! Mar 03 19:48:23 hi Mar 03 19:48:30 Did someone try to build Qt 4.8 on Maemo ? Mar 03 19:49:30 ... maybe it is complete non-sense, as there seem to be not so much support for that platform anymore Mar 03 22:08:44 Test Mar 03 23:08:57 pali, are you here? Mar 03 23:09:11 Hurrian, yes Mar 03 23:13:56 was thinking of patching 2.6.29 to run Maemo - it's not a big jump, and no kernel drivers that we care about are removed Mar 03 23:14:04 any blockers? i can merge .rej files myself Mar 03 23:19:53 Hurrian, I will try to use last meego/nemo kernel on maemo5 Mar 03 23:20:06 2.6.29 is too old Mar 03 23:34:55 :O Mar 03 23:35:12 -110 error needs to be fixed first ;) Mar 03 23:36:02 last time anyone tried, didn't it just end in Maemo going MALF? Mar 03 23:50:10 Hurrian, problem is that in meego kernel was deleted /proc/bootreason and fremante gpio keys interface too Mar 03 23:50:29 but I have patch which reverted that back Mar 03 23:51:18 last time when I tested it in qemu I got starting X Server and that was all, because I did not have compiled qemu kgles2 module for X Server Mar 03 23:52:13 maybe it is time to test it on real n900 :D Mar 03 23:52:44 freemangordon, see ^^^^^ Mar 03 23:54:26 ah Mar 03 23:54:31 OOOOOH Mar 03 23:54:44 i wanna see that! Mar 04 01:31:50 semi-OT: http://javad.com/downloads/javadgnss/publications/20112312.pdf (GPS [+ mobile phones]) Mar 04 01:49:52 intresting read Mar 04 01:53:59 it better be :) Mar 04 01:55:55 i saw the word filter and had nightmares of analog electronics class Mar 04 02:00:35 tank-man: like 99.9% of EE staff that was responsible of building mass products from some crappy reference design done in USA Mar 04 02:00:53 It's largely irrelevant. Mar 04 02:01:03 Sure - better filters can be designed. Mar 04 02:01:21 However, the problem is that aviation GPSs often have _long_ lifes. Mar 04 02:01:35 And would not normally be replaced because they're 5 years old. Mar 04 02:01:54 (because they are expensive!) Mar 04 02:02:22 This means that if L^2 goes ahead - much of the installed infrastructure for airborne GPS needs replaced. Mar 04 02:02:28 nah, the problem is that EE staff didn't consider to use better (not asking for 'optimal') filters in those friggin expensive aviation GPS Mar 04 02:02:55 The bandplan specifically says that it's supposed to be a quiet low-power zone. Mar 04 02:03:05 It's not unreasonable to design on that basis. Mar 04 02:03:48 errr Mar 04 02:04:46 not in compliance with my rule of "be conservative in what you do, be liberal in what you expect from others" Mar 04 02:04:53 I agree. Mar 04 02:05:05 From an ideal POV it's not great. Mar 04 02:05:35 But as an in-reality design, limited by cost, it's not unreasonable to design to regulations + a buffer. Mar 04 02:05:54 Without expecting signals a million times stronger in the skirts. Mar 04 02:06:07 not if it turns out a better filter is even cheaper Mar 04 02:06:24 Only if cheaper is cheaper in terms of design time too. Mar 04 02:06:28 they were outright *lazy* to even think about it Mar 04 02:09:00 esp for a GLOBAL POSITIONING system for AVIATION, how could they expect whole world folows their fubar idea of FCC regulations? Mar 04 02:09:36 Dude we're aviation, we always get our way Mar 04 02:09:40 even at design time they couldn't guarantee this is "supposed to be a quiet low-power zone" globally Mar 04 02:10:09 passengers buying cheap water bottles outside of airport and bringing onto airplane, onboard refreshments sales dropping? No problem, ban water. Mar 04 02:13:21 now add in the rationale of this guy that a better filter design improves the GPS accuracy and TTFF even without any L^2 around, and you start to ask what the F* those EE had in their design specs when they designed the schematics for a $$$$$$ aviation device Mar 04 02:14:24 btw Mar 04 02:14:42 I don't remember this exactly Mar 04 02:14:47 but it's about the transponder design Mar 04 02:15:52 If airplane A and airplane B are at 1km and 2km north of an airport, their transponder signals get ORed Mar 04 02:16:22 (or something like that) Mar 04 02:17:07 It's not. Mar 04 02:17:11 transponder accuracy might well be worse than 1km resolution Mar 04 02:17:12 This is about GPS. Mar 04 02:17:28 And a proposal to put a high power internet service _right_ next to the GPS signal. Mar 04 02:17:41 Um, I meant that as in "btw about aviation EE design" Mar 04 02:17:42 is insane, agreed Mar 04 02:18:17 I did not mean that the article above is about transponders in any way Mar 04 02:18:22 ah Mar 04 02:18:34 Sorry - I'm not properly awake. Mar 04 02:18:48 propagation delay in transponder is probably main issue about all that Mar 04 02:19:10 However, the current transponder system makes signals add up and bitwise OR together when airplanes are in certains locations relative to ground receiver Mar 04 02:19:27 Well, the regular transponder only has ID and altitude, no position data Mar 04 02:19:37 and duration to TX the 'telegram' is way longer than the time skew between two planes 1km apart from each other Mar 04 02:20:01 however, there are special ID codes reserved for "Help, I'm hijacked and everything I say is a lie" Mar 04 02:20:26 fx Mar 04 02:20:30 * SpeedEvil is awaiting a GPS research board. Fun. Mar 04 02:20:39 the position data is based on radar principle Mar 04 02:20:50 Someones making a few prototypes, which should allow fun stuff. Mar 04 02:21:01 STM32F can do correlation from a raw baseband chip Mar 04 02:21:02 that's why propagation delay in transponders is of any concern Mar 04 02:21:03 Fun. Mar 04 02:21:41 Some of the new arm microcontrollers are getting silly. Mar 04 02:22:01 So if two airplanes with transponder identification codes that when bitwise ORed with eachother add up to that emergency code passes close to eachother, it triggers an alarm in the air traffic control, and the airplanes when landing will be greeted by a swat team :P Mar 04 02:22:57 anyway I guess transponders do implicit TDMA, by simple difference in distance to airport transceiver Mar 04 02:23:46 so if two airplanes are in line as seen from airport, they have to be separate from each other by at least telegram TX duration Mar 04 02:23:55 otherwise "media collision" Mar 04 02:26:15 of course you could do a completely different scheme: e.g. correlate the time of rx the radar pulse to some (e.g. GPS based) global clock, then send this tuple back to tower out-of-band with arbitrary time delay Mar 04 02:26:58 Unless you can say 'planes with bit 4 unset do not transmit' Mar 04 02:27:00 and possibly even a protocol layer above it to secure transmission against packet loss Mar 04 02:27:21 In which case you can work out which aren't. Mar 04 02:29:47 You know in places you still have to navigate by using the radio direction finder to determine the bearing to AM beacons :) Mar 04 02:31:43 yeah, and doing some addr decoding in transponder isn't possible I'd guess. Introduces too much propagation delay Mar 04 02:32:49 I don't even know if RADAR from tower is carrying any info at all, or is just a simple pulse Mar 04 02:33:06 pulse Mar 04 02:33:13 to which the transponder answers in 'no time' Mar 04 02:34:48 There's a separate FM system at 108 - 118 Mhz (iirc) that's slightly more sophisticated than the radio direction finding, the aircraft can determine the bearing from radio station to itself Mar 04 02:35:11 hard to do any CDMA/CD scheme or MAC addressing on such a media channel Mar 04 02:35:51 FM lighthouse Mar 04 02:36:08 sending directionally unique signals Mar 04 02:37:18 send a unidirectional beacon pulse followed by a directional sweep Mar 04 02:37:48 time diff between beacon and sweep will tell you relative angle to lighthouse Mar 04 02:38:43 s/uni/omni/ Mar 04 02:39:06 "A VOR ground station sends out a master signal, and a highly directional second signal that varies in phase 30 times a second compared to the master. This signal is timed so that the phase varies as the secondary antenna spins, such that when the antenna is 90 degrees from north, the signal is 90 degrees out of phase of the master. By comparing the phase of the secondary signal to the master, the angle (bearing) to the station can be determined." Mar 04 02:39:53 well, basically what I said Mar 04 02:41:56 just that they use the carrier of the omnidirectional beacon itself as a time base Mar 04 02:43:06 while I wonder how you're supposed to either a) receive two signals of exactly same frequency, or b) correlate phase of two signals with different frequency Mar 04 02:44:22 well, maybe they don't send the 'master' beacon continuously, but actually do it like I said Mar 04 02:45:13 and all that phase voodoo is just describing the encoding of the time skew vs angle to tower Mar 04 02:46:20 so the receiver doesn't need to detect exact moment the sweep signal comes in, but rather look at phase of that signal Mar 04 02:50:02 AAAH, now I even parsed the "30 times a second" part Mar 04 02:51:20 that's probably the TDMA freq of master and sweep signal Mar 04 02:55:07 I gather the beacon is of noticeably different duration than the sweep signal, so receiver can distinguish the both Mar 04 02:58:07 In 1940 this thing was implemented by two antennas, one fixed antenna, and one directional antenna. The directional antenna was made to spin around by a motor. **** ENDING LOGGING AT Sun Mar 04 02:59:58 2012