| 23:05 | g3gg0__ | left the channel |
| 23:14 | baldand | left the channel |
| 23:16 | baldand | joined the channel |
| 23:22 | Bertl | depends on the display used, most LCDs bring their own framebuffer
|
| 23:25 | davidak | left the channel |
| 23:28 | intracube | Bertl: ah ok, interesting
|
| 23:54 | Bertl | and with pixel accurate I mean fonts which are not variable over the display
|
| 23:54 | Bertl | i.e. a specific letter of a specific size will always be rendered the same, regardless where it is used
|
| 23:55 | Bertl | (this simplifies a lot of things)
|
| 23:55 | Bertl | using fixed width fonts is another step, but that is probably only useful/necessary with numbers and similar
|
| 23:56 | intracube | Bertl: so they could be anti-aliased?
|
| 23:56 | Bertl | color LCDs are quite common, so monochrome is not that much an advantage
|
| 23:56 | Bertl | i.e. you can usually convert a given symbol to any color (from gray) on the fly
|
| 23:57 | Bertl | still it adds code and probably needs to be implemented :)
|
| 23:58 | intracube | it'll be interesting to follow this area
|
| 23:59 | Bertl | as I said, it is usually very informative to try to implement some ideas e.g. with SDL
|
| 23:59 | intracube | Bertl: can parts of screen frame-buffers be written to in isolation?
|
| 23:59 | intracube | as in, could a small area of the display (single character) be overwritten
|
| 23:59 | intracube | or would the whole screen have to be calculated and passed to the buffer
|
| 23:59 | Bertl | again, depends on the display
|
| 00:00 | intracube | ok :)
|
| 00:00 | Bertl | that was why I was asking for sizes/resolution
|
| 00:01 | intracube | i.e. redrawing the timecode would be more efficient if only the changing characters needed to be redrawn
|
| 00:01 | intracube | knows nothing about this area
| | 00:03 | Bertl | http://minhdanh2002.blogspot.co.at/2011/03/interfacing-nokia-3510i-and-5110-lcd.html
|
| 00:03 | Bertl | here you can get an idea for a specific (very common) group of displays
|
| 00:04 | intracube | thanks, will have a read
|
| 00:05 | Bertl | most LCDs have a controller chip integrated, which takes care of handling the data, but doesn't support any drawing algorithms
|
| 00:05 | Bertl | you can usually read and write the frame buffer, but not at high data rates
|
| 00:33 | fsteinel_ | joined the channel |
| 00:37 | fsteinel | left the channel |
| 00:54 | intracube | even 320x240 might be ok: https://lh3.googleusercontent.com/-ItG1QaK0v2U/VH5tCn1Sr3I/AAAAAAAAA9M/5LUSQk9Ip1k/w320-h240-no/apertus_control_320x240_test.png
|
| 00:58 | mooseboobs | left the channel |
| 00:58 | mooseboobs | joined the channel |
| 01:19 | fsteinel_ | changed nick to: fsteinel
|
| 01:21 | intracube | left the channel |
| 01:43 | even_ | left the channel |
| 02:12 | slikdigit | left the channel |
| 03:23 | aombk2 | joined the channel |
| 03:26 | aombk | left the channel |
| 03:36 | ItsMeLenny | joined the channel |
| 04:36 | ItsMeLennny | joined the channel |
| 04:37 | ItsMeLenny | left the channel |
| 04:43 | ItsMeLennny | left the channel |
| 04:44 | ItsMeLennny | joined the channel |
| 05:02 | ItsMeLennny | left the channel |
| 05:58 | Bertl | off to bed now ... have a good one everyone!
|
| 05:58 | Bertl | changed nick to: Bertl_zZ
|
| 06:01 | FransKanters | joined the channel |
| 07:57 | g3gg0 | joined the channel |
| 09:18 | surami | joined the channel |
| 09:52 | surami | left the channel |
| 12:13 | intracube | joined the channel |
| 12:27 | davidak | joined the channel |
| 12:42 | Bertl_zZ | changed nick to: Bertl
|
| 12:42 | Bertl | morning folks!
|
| 12:58 | se6astian|away | changed nick to: se6astian
|
| 12:58 | se6astian | good day!
|
| 13:11 | se6astian | Bertl: is http://lab.apertus.org/T200 answered to your satisfaction for now?
|
| 13:19 | designbybeck_ | joined the channel |
| 13:43 | Bertl | yes, I'd say so, note that "normal" displays have a resolution of around 72 dpi, so 150 dpi is quite high (just a note)
|
| 13:49 | se6astian | did I calculate it wrong? I used this as reference: http://www.watterott.com/de/MI0283QT-2-Adapter
|
| 14:02 | Bertl | no, calculation is fine
|
| 14:28 | intracube | small displays are usually viewed closer up
|
| 14:29 | intracube | 70-90ppi is common for desktop displays
|
| 14:30 | intracube | 150ppi = 640x480 for a 5" screen
|
| 14:31 | intracube | which seems reasonable
|
| 14:33 | intracube | iphone 6+ has 400ppi screen
|
| 15:03 | surami | joined the channel |
| 15:26 | FransKanters | left the channel |
| 17:30 | dmjnova | joined the channel |
| 18:00 | even | joined the channel |
| 18:00 | even | hellos
|
| 18:01 | mars_ | hi even
|
| 18:01 | Bertl | odd :)
|
| 18:02 | even | howcome? :D
|
| 18:05 | lab-bot | sebastian created T201: Research pushbutton switch options. http://lab.apertus.org/T201
|
| 18:07 | even | question: did you guys ever try to stream something via network on the alpha by using gstreamer for instance? if so.. did u measure the delay? glas to glas that is. i'm curious about those numbers
|
| 18:18 | Bertl | streaming over network means roughly 0.05 - 0.1 FPS (raw data) so the delay is significant :)
|
| 18:18 | Bertl | and no, we never really "streamed" anything over network
|
| 18:20 | even | thank you
|
| 18:21 | even | imagine a flying gamma.. what do we need to get a close to 0 low latency stream. something thats below 100ms 720p would be fine
|
| 18:21 | even | i'm thinking about fpv flight
|
| 18:26 | even | dji is selling a 1080p streaming solution for fpv for >1000€ and in those fpv forums people are developing solutions for the raspberry pi + picam + Ubiquiti wifi adapters
|
| 18:27 | dmjnova | even: I imagine an onboard encoder streaming a proxy would be plausible
|
| 18:28 | dmjnova | we would need to downres/compress to some degree on the axiom itself before giving it to the pi
|
| 18:29 | dmjnova | or perhaps run gstreamer on the ARM cores on the zedboard
|
| 18:30 | dmjnova | even: I once made a raspberry pi + webcam + wifi dongle streaming system for a groundbot
|
| 18:30 | even | how was the experience? =)
|
| 18:31 | dmjnova | It actually worked quite well with a PC as reciever. There were issues with HD when using a smartphone.
|
| 18:34 | dmjnova | the main challenge was pretty much turning the pi into a wifi router
|
| 18:35 | dmjnova | after that, it was just making a gstreamer pipeline
|
| 18:35 | even | so u were using 720p at 49fps as well i suppose?
|
| 18:35 | dmjnova | don't remember the framerate, probably 30fps
|
| 18:36 | dmjnova | and 720p to the PC
|
| 18:36 | even | ok well you get less delay when using 49fps =)
|
| 18:36 | dmjnova | for smartphone usage had to drop it much lower
|
| 18:36 | dmjnova | the webcam might've been the determining factor there
|
| 19:00 | g3gg0_ | joined the channel |
| 19:03 | even | ok hmm do you know any hardware encoders h264/265 encoders that are capable of being almost 1:1 fast?
|
| 19:03 | g3gg0 | left the channel |
| 19:05 | even | according to forums the dji lightbridge has delays from 150ms-180ms
|
| 19:05 | derWalter | joined the channel |
| 19:07 | derWalter | left the channel |
| 19:07 | even | which is too slow for me =)
|
| 19:09 | even | or did you maybe try out one of these teradek thingys and have some experience?
|
| 19:11 | Bertl | even: you might be able to implement motion jpeg in the FPGA
|
| 19:12 | Bertl | that should give you almost instant encoding (like 20-30 rows delay)
|
| 19:12 | dmjnova | even: I ended up going for mjpeg
|
| 19:16 | even | Bertl: sounds great =)
|
| 19:31 | even | i already put some work in the flightcontroller. but it's not done yet. still fiddling around with the design https://eveninfinite.com/pics/axis/axis_tight_8k.jpg
|
| 19:33 | Bertl | looks a little bit like a playstation/xbox controller with a monitor :)
|
| 19:33 | even | haha you got me
|
| 19:34 | dmjnova | not sure flight controller is the right description for that
|
| 19:34 | even | flightcontroller is the software/hardware combination
|
| 19:34 | dmjnova | usually "flight controller" means the microcontroller on the uav
|
| 19:34 | dmjnova | least that was my impression
|
| 19:35 | dmjnova | that's more a handheld ground station
|
| 19:37 | dmjnova | sorry if that's pedantic
|
| 19:37 | even | no worries =) the middle part will be modular
|
| 19:37 | even | heres some more early pics https://eveninfinite.com/pics/axis/
|
| 19:38 | even | are*
|
| 19:39 | dmjnova | already looked at 'em
|
| 19:39 | dmjnova | what software will that run?
|
| 19:39 | dmjnova | Is that just fpv or full mission control?
|
| 19:41 | even | full mission control and fpv including 3d splines and automated gimbal movement
|
| 19:42 | even | the monitor is a tablet
|
| 19:42 | even | will be*
|
| 19:55 | even | the app is called axis but is still in very early stages. android/ios
|
| 20:00 | mooseboobs | left the channel |
| 20:01 | even | and the cam will be the gamma =)
|
| 20:08 | surami | left the channel |
| 20:11 | Bertl | off for a nap ... bbl
|
| 20:11 | Bertl | changed nick to: Bertl_zZ
|
| 21:10 | dmjnova | even: will axis be open source?
|
| 21:11 | dmjnova | even: what's your experience with UAVs?
|
| 21:37 | davidak | left the channel |
| 21:38 | davidak | joined the channel |
| 22:03 | davidak | left the channel |
| 22:03 | davidak | joined the channel |
| 22:17 | Bertl_zZ | changed nick to: Bertl
|
| 22:17 | Bertl | back now ..
|
| 22:35 | davidak | left the channel |
| 22:45 | dmjnova | left the channel |
| 22:49 | even | dmjnova: not at this stage. but i have no problem opening it as soon as it works. the tablet will be connected to the controller. i will probably start milling the parts in february as soon as im done with the details.
|
| 22:49 | fsteinel | changed nick to: lenietsf
|
| 22:51 | se6astian | changed nick to: se6astian|away
|
| 22:51 | even | dmjnova: i've been flying stuff for about 2 years and i ordered an autoquad fc 2 days ago from flyduino.net so i can test my 3d spline exporter that already works =)
|