(...)Gilles, this was all on Windows. The latest code still gives lines/blocks here. I actually tried a different USB port and it is worse, much much worse
I started working on new code to use ftdi_readstream as it may improve the reading performance but it is not working (yet), I just get blank images. Not sure if I am using it correctly, there is not much documentation out there.
Happy to be listed as an author, thank you.(...)
Ok give me your name, or if you prefer i can just say "Luka from IceInSpace Forum" with a link to this thread.
I've also awkwardly tried these "asynchronous" functions with cam84, but with no chance...
If you achieve this it will be fantastic !
BTW : have you simple hints to use github correctly ? i've reached my limits and i'd like to understand the way things should be done (how should we work on the same file ? if i merge your pull request, i loose my local changes for other stuff, a fiew lines further... should i merge manually ?)
One litte guess :
Flolic, obviously you look to build your stuff very wisely
I've seen on your pictures that you are twisting wires : what is the purpose ? is it like on my valve amps, where we have to twist wires to avoid interferences between heating circuitery and signals ????
Might it be the same for usb signals and alimentation ?
I think there might be something here because when i move my cam86, i sometimes get no "lines" and sometimes i get some...
My power supply is a mini switching one, and it might be a point i should have a look at.
Gilles.
Gilles, USB data wires should be twisted and shortest possible. The purpose of that is to preserve signal integrity, by reducing electromagnetic interference and possible crosstalk.
Googling "twisted pair" will give you much more info
Gilles, USB data wires should be twisted and shortest possible. The purpose of that is to preserve signal integrity, by reducing electromagnetic interference and possible crosstalk.
Googling "twisted pair" will give you much more info
Thank you, that's it, i'll do that tonight.
And what about power supply wires ?
EDIT : i googled that last point, and it seems not to have any effect.
i will try to plug another regular supply (ie not switching...) just to test...
Managed to fit FTDI LQFP64 and ATMega328P and associated power then tried programming them...ahhh yeah didn't go so well at first. I was getting the following error... "Error reading device" in MProg.
Apparently I needed to fit the EPROM IC DD2 to the PCB, MProg was not reading the FDTI properly because its EPROM was missing! Go figure. Sigh!
Anyway after installing it ..all went well. Fusebits done, ATMEGA328P programmed, cam86 ASCOM installed ok, connected to cam86 view fine. Although not much to see as the PCB only has enough fitted to do firmware.
Luka you should post your pictures on the Ukrainian forum, because we are not alone now, 1 others to the same problem.
Between all should have found the solution!
Gilles, I PM-ed you my name for the github. Thank you for including me.
Also, if I can add to Filip's comment, the keep the lengths of the twisted data lines the same.
Regarding the github, I am far from expert but when you start changing code you should never do it on the master branch, i.e. start a new branch, do coding and when happy with it merge it. That way the overwriting code can be avoided. Also you can (somehow?) give me permissions to the repository which will give me the same rights as you. This will let me start a new branch and do changes there. You can always change branches and see what I am doing and otherwise. But if you give me permissions you lose 100% control
Right now I had to fork your code, do changes on my fork and do a pull request for you to review. It gets messy that way as you have seen.
Great work Brendan Keep populating the board, you are almost there.
And that was a great shot of dark matter
Pat, I am waiting for approvals to join the Ukrainian forum.
By the way, some info for our European friends, I am in Perth which is at the moment 7h ahead of you. Few other guys are on the east coast of Australia which is 10h ahead of you.
By the way, some info for our European friends, I am in Perth which is at the moment 7h ahead of you. Few other guys are on the east coast of Australia which is 10h ahead of you.
It's really complicated for the Kangaroo, 1 country and five different times
It is even worse, some states have daylight savings while some don't. I never know what the time difference to the east coast is and need to use google to find it out.
Gilles, I PM-ed you my name for the github. Thank you for including me.(...)
Regarding the github, (...)
Your name is in the author file.
I don't want to keep 100% control on what is not 100% mine : i've tried to add you as a "collaborator", i think you have to accept before i can grant any access to you...
Let's give it a try.
And i'll follow your advice : for now i will try to work only a branch ("gehelem"...)
Gilles.
It has some vertical banding issues I am dealing with thru testing various horizontal driver filter caps, and frame std deviation is high, I need to work on this as well.
Here is an image with camview. gain offset at zero, sensor covered (if I uncover it the frame is all over the place).
It has some vertical banding issues I am dealing with thru testing various horizontal driver filter caps, and frame std deviation is high, I need to work on this as well.
Here is an image with camview. gain offset at zero, sensor covered (if I uncover it the frame is all over the place).
Hi Pat I'm pretty sure you're correct...but in the mean time...fiddling around DD8....with caps...all of sudden it won't connect to camview...the 3.3V reg is getting hotter and I draw is now higher 238mA.
Which is not a lot but the regulator is sure heating up more.
I did some more "dark tests" and the camera was performing ok a little high on std deviation but could be sensor heat.
So I need to go back to find the failure!
Brendan
edit edit:
Hey the previous I draw measurements were wrong ...the following is correct:
...Anyway looking at the I draw I said I have 230mA. Other users mention ~220mA so this is not "out of this world". My previous I draw tests were incorrect as I was measuring total I draw not just 3.3V I draw.
I cut the gnd of DD12 (3.3V reg) and put an ammeter in series. It draws 107mA. @10V in (actually 107mA 8V ~12V in). That's a 6.7V drop across the regulator and this at .1A is ~ 0.67Watts VDrop across the regulator! Its a little too much too much its rating is ~100mA and we are there now.
Brendan
Last edited by wasyoungonce; 25-01-2017 at 07:08 PM.
@Luka
i've just made changes to our driver, to merge with the recent Delphi code given by Rome from the Ukrainian forum.
I've also discovered a "FTDI read data hack" into library provided for QSI camera
They obviously seem to use ftdi chips, and i've taken their code.
=> i have no more "blocks" ! (for the moment...)
Gilles, did you try the new code on the Raspberry Pi or are blocks gone only on your PC?
I tried it here and I still get blocks on my PC. The new code for ftdi_read_data function is very similar to our old code with timeouts. One thing that did change is the reduction of the size of the read buffer from 65536 to 16384 (1<<14) but this is giving me more lines/blocks.
My attempts to use asynchronous reads are not going anywhere, it reads data even when there is none to be read . I was sick but am feeling better now and may have another look at this.
Also my Windows laptop that had lines has died, now I only have the new one that almost never shows lines.
Keep populating the board, you are almost there.
, you made my being-sick-in-bed much, much more bearable 
. I was sick but am feeling better now and may have another look at this.
