BenningtonCS / Telescope-2014

4 stars 0 forks source link

install latest version of 64-bit RHEL on new machine instead of Ubuntu #67

Closed acencini closed 10 years ago

acencini commented 10 years ago

via @hcrowl (he can provide more specifics from wesleyan)

they are using RHEL for their linux distro. we should get this running on the tower asap and get v2 and v3 built there, and hook up the dongle and rotator to that machine and make sure this is indeed a platform issue.

and of course, documentation of all of this will be critical. until we can fix the ubuntu version, we should focus on "just getting it working" on RHEL and then we can figure out the bugs and pick up the pieces.

@Kgespada @vpascow @edaniszewski

acencini commented 10 years ago

55 (related)

acencini commented 10 years ago

Red Hat Enterprise Linux Client release 5.8 (Tikanga) with a 2.6.18 kernel.

edaniszewski commented 10 years ago

It looks like RHEL 5.8 was released in 2009, and since its currently at 6.5 and 7.0 was announced, it looks like they no longer support 5.8.. I can do a bit more digging, but from a quick look, it seems like we might have to settle for a 6.something release. Hopefully it's backwards compatible.

acencini commented 10 years ago

that was the known good configuration from wesleyan so we could try a recent version and then backtrack if it is problematic.

theDarkLard commented 10 years ago

As @edaniszewski had warned me, I can't find any free downloads of RHEL, older or new releases. Maybe my digging sucks but we might have to fork over some bills to get this thing going.

edaniszewski commented 10 years ago

I'll do some more digging... I might be able to acquire a copy through questionable means.

On Thursday, March 27, 2014, theDarkLard notifications@github.com wrote:

As @edaniszewski https://github.com/edaniszewski had warned me, I can't find any free downloads of RHEL, older or new releases. Maybe my digging sucks but we might have to fork over some bills to get this thing going.

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-38874425 .

hcrowl commented 10 years ago

Another option may be some of the De-enterprised versions of RHEL. If I recall correctly, Scientific Linux (https://www.scientificlinux.org) is basically RHEL for free.

edaniszewski commented 10 years ago

Fedora may also be an option to consider since it and REHL are related.. http://fedoraproject.org/en/get-fedora

edaniszewski commented 10 years ago

To make USB bootable (from a mac): http://borgstrom.ca/2010/10/14/os-x-bootable-usb.html

I tried this out and it seemed to work.

I also installed a version of Fedora quickly to see if it would run srtn. I got gcc, gtk2, libusb, and git using the yum package manager, and tried to run it. It threw the error that the libraries could not be found and they should be added to the path. Before I could fix it, I had to leave for the weekend. If anyone else wants to try and figure out where packages are stored on Fedora and how to update the path, try it out and see if srtn will run!

If not, we should try Scientific Linux.

I'll also spend a bit of time seeing about finding a desktop version of RHEL. I managed to find a server version but I'm not sure that will be helpful.

edaniszewski commented 10 years ago

Got Fedora installed, after some trial, found proper packages, installed them, then ran srtn. Results are not good. Appears to be having same problems as on Ubuntu plus more. I built our version, which may be hacked to the point of causing the errors. I need to do something else now, but later I will see about installing/compiling and running from a clean install (of srtnver3, and if that doesnt work, srtnver2)

results and outline of process can be found on wiki page: https://github.com/BenningtonCS/Telescope-2014/wiki/Installing-Source-on-Fedora

acencini commented 10 years ago

from the image, i see an assertion failure around font != NULL in other words, the programmer was asserting that the font should never be null before reaching a given point in code.

if i were to guess, it might be interesting to see if the GTK fonts are being found properly.

i'd also strongly suggest using a clean start of srtv3 before folding in changes. strnv2 should hopefully "work" though.

the maxes and mins do not look good, still. according to @hcrowl wesleyan is still on v2. i can look into the font finding failures, as i hope that is just a simple configuration thing.

On Sun, Mar 30, 2014 at 9:21 PM, Erick Daniszewski <notifications@github.com

wrote:

Got Fedora installed, after some trial, found proper packages, installed them, then ran srtn. Results are not good. Appears to be having same problems as on Ubuntu plus more. I built our version, which may be hacked to the point of causing the errors. I need to do something else now, but later I will see about installing/compiling and running from a clean install (of srtnver3, and if that doesnt work, srtnver2)

results and outline of process can be found on wiki page: https://github.com/BenningtonCS/Telescope-2014/wiki/Installing-Source-on-Fedora

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39046964 .

hcrowl commented 10 years ago

How concerned are we (and/or should we be) that the MIT people are running an AMD processor and we are running Intel?

edaniszewski commented 10 years ago

Yeah, I'm going to try it with a clean install now -- I'll post the results when I get them!

I'm not sure about the AMD/Intel question, I'll leave that to @acencini to reason out. It might have something to do with it though. I guess we can always try installing Ubuntu or Fedora on a Raspberry Pi to see if that will work..

acencini commented 10 years ago

are they running AMD at Wesleyan?

if so, i have a couple AMD boxes kicking in the server room that we could throw a video card into to see if they would work better (or we could test-run headless, though we'd need to install fedora on those)

On Sun, Mar 30, 2014 at 9:38 PM, Erick Daniszewski <notifications@github.com

wrote:

Yeah, I'm going to try it with a clean install now -- I'll post the results when I get them!

I'm not sure about the AMD/Intel question, I'll leave that to @acencinihttps://github.com/acencinito reason out. It might have something to do with it though. I guess we can always try installing Ubuntu or Fedora on a Raspberry Pi to see if that will work..

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39047499 .

edaniszewski commented 10 years ago

Results, lets start with the easiest:

srtnver2

When running srtnmake, it fails with the error

[radiotelescope@localhost srtnver2]$ ./srtnmake 
gcc: error: /usr/lib/libgfortran.a: No such file or directory

srtnver3

Out of the box

When running 'straight out of the box', we get the result:

Which shows that it works (with no changes.. not even the srtnmake script had to change to include gtk+-2.0 in the gcc params) But at this point, both antenna motion and receiver are simulated, which isnt useful

Non-simulated reciever, simulated motion

When we tell it to use data from our dongle, we get this result:

So, it sees the data coming in from the dongle (or, it sees some kind of data) and is able to plot it (but still not able to plot any text) and the !=NULL messages still exist.

Non-simulated reciever and motion

This just starts out like it should, but before the GUI even shows up, the program crashes.

acencini commented 10 years ago

so it seems to be unable to find the fonts (probably explains why there is no text in the drawn window)

it might make sense to verify that the fonts are set up correctly with gtk+2.0 and that the font path exists, etc.

from there it would then make sense to trace for a call to gdk_draw_text or something that writes text to the screen/sets up the fonts srtn is using, and see if you can see what's shaking there - if the previous stuff doesn't help. --a

On Sun, Mar 30, 2014 at 9:49 PM, Erick Daniszewski <notifications@github.com

wrote:

Results, lets start with the easiest:

srtnver2

When running srtnmake, it fails with the error

[radiotelescope@localhost srtnver2]$ ./srtnmake gcc: error: /usr/lib/libgfortran.a: No such file or directory

srtnver3

Out of the box

When running 'straight out of the box', we get the result:

https://camo.githubusercontent.com/64a61e081a2e694de8ed4c813fe78a03695c8235/687474703a2f2f692e696d6775722e636f6d2f77437a766269542e706e67

Which shows that it works (with no changes.. not even the srtnmake script had to change to include gtk+-2.0 in the gcc params) But at this point, both antenna motion and receiver are simulated, which isnt useful Non-simulated reciever, simulated motion

When we tell it to use data from our dongle, we get this result:

https://camo.githubusercontent.com/abdd2c5b64e018767aff0a2ede8fa81cb71caa8e/687474703a2f2f692e696d6775722e636f6d2f486b486a30696a2e706e67

So, it sees the data coming in from the dongle (or, it sees some kind of data) and is able to plot it (but still not able to plot any text) and the !=NULL messages still exist. Non-simulated reciever and motion

This just starts out like it should, but before the GUI even shows up, the program crashes.

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39047876 .

acencini commented 10 years ago

i have an amd machine at home - i will bring it in tomorrow

hcrowl commented 10 years ago

Cool. I've confirmed with Wesleyan that they are running the software on an AMD machine.

acencini commented 10 years ago

also when we build via srtnmake we should likely use the AMD FFT as opposed to the Intel FFT. though we should investigate the matrix of possibilities starting with the most intuitive options (build on AMD/Fedora w/AMD FFT first) then moving to other options.

edaniszewski commented 10 years ago

@acencini do we have an AMD machine now with new hard drive? If its in the physics lab, I can probably get Fedora and the packages we need loaded before class

acencini commented 10 years ago

it is in my office but has the existing hd in it at the moment

On Tue, Apr 1, 2014 at 11:20 AM, Erick Daniszewski <notifications@github.com

wrote:

@acencini https://github.com/acencini do we have an AMD machine now with new hard drive? If its in the physics lab, I can probably get Fedora and the packages we need loaded before class

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39218062 .

acencini commented 10 years ago

i just swapped in a 2Tb hdd that can be wiped and the machine is sitting in the lab

all users - please be gentle with the machine as it is my personal computer!

On Tue, Apr 1, 2014 at 11:56 AM, Andrew Cencini acencini@gmail.com wrote:

it is in my office but has the existing hd in it at the moment

On Tue, Apr 1, 2014 at 11:20 AM, Erick Daniszewski < notifications@github.com> wrote:

@acencini https://github.com/acencini do we have an AMD machine now with new hard drive? If its in the physics lab, I can probably get Fedora and the packages we need loaded before class

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39218062 .

hcrowl commented 10 years ago

Email from Alan Rogers (MIT) via Meredith Hughes (Wesleyan U.):

Hi Hugh,

Ah, yes! Been there, done that. Here are the helpful emails I received from Alan and Tim last year about the flavor and version of Linux they built the software on. We just installed exactly the same stuff (64 bit) and it worked. Haven't changed anything since, because I'm afraid to.

Meredith

Hi Meredith,

The machine is running Red Hat Enterprise Linux Client release 5.8 (Tikanga) with a 2.6.18 kernel. CentOS may be worth considering, given their focus on full binary compatibility with RHEL. Detailed system information is attached.

And just to mention it, there are newer drivers out there for the PCI-DAS 4020/12 card. (With 3.x kernel support.)

Regards, Tim

Dear Meredith, The minimum requirements for the PC using the current code is a PCI slot and an AMD processor. The only operating system currently supported is Linux kernel 2.6 or later. With help from a student in IT you could:

1] Get the FFT software for an Intel processor

2] Convert to Windows - a windows driver is available for the PCI-DAS4020/12 ADC card.

3] Use a MAC

We are planning on doing some further development this summer I hope to release an update for the Linux version using the AMD processor and pending more tests we may put out a version using a Realtek USB TV dongle instead of the PCI-DAS4020/12 card - I would still plan to use Linux and leave it up to the user to convert to other operating systems. I realize that many users would prefer Windows (as in the old SRT) but currently I have no help or plans to make the conversion. I think you should consider a new PC with PCI, AMD processor and Linux. If you pick out one your IT likes you might want to check the model with us before you purchase it. I expect there are some Linux users at Wesleyan? You might want to talk with one of them and your IT person.

             best regards Alan

Detailed information from Tim's attachment:

Linux reu5 2.6.18-308.1.1.el5 #1 SMP Fri Feb 17 16:47:13 EST 2012 i686 athlon i386 GNU/Linux

Red Hat Enterprise Linux Client release 5.8 (Tikanga)

processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 1 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow nonstop_tsc pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy 3dnowprefetch ts fid vid ttp tm stc 100mhzsteps bogomips : 2009.10

processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 1 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow nonstop_tsc pni cx16 lahf_lm cmp_legacy svm extapic cr8legacy 3dnowprefetch ts fid vid ttp tm stc 100mhzsteps bogomips : 2009.10

MemTotal: 2073904 kB MemFree: 1817544 kB Buffers: 17088 kB Cached: 155580 kB SwapCached: 0 kB Active: 81316 kB Inactive: 149660 kB HighTotal: 1178496 kB HighFree: 957512 kB LowTotal: 895408 kB LowFree: 860032 kB SwapTotal: 2096472 kB SwapFree: 2096472 kB Dirty: 12 kB Writeback: 0 kB AnonPages: 58420 kB Mapped: 10492 kB Slab: 12904 kB PageTables: 1332 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 3133424 kB Committed_AS: 125400 kB VmallocTotal: 114680 kB VmallocUsed: 5736 kB VmallocChunk: 108768 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize: 4096 kB

dmidecode 2.11

SMBIOS 2.5 present. 33 structures occupying 1242 bytes. Table at 0x000F0000.

Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: Dell Inc. Version: 1.0.3 Release Date: 06/15/2007 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 512 kB Characteristics: PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/360 kB floppy services are supported (int 13h) 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 1.0

Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: Inspiron 531 Version: 00 Serial Number: BTN2QD1 UUID: 44454C4C-5400-104E-8032-C2C04F514431 Wake-up Type: Power Switch SKU Number:
Family:

Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: Dell Inc. Product Name: 0RY206 Version: ... Serial Number: ..CN6986177E0617.

Handle 0x0003, DMI type 11, 5 bytes OEM Strings String 1: www.dell.com

Handle 0x0004, DMI type 3, 17 bytes Chassis Information Manufacturer: Dell Inc. Type: Desktop Lock: Not Present Version: Chassis Version Serial Number: BTN2QD1 Asset Tag:
Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000000

Handle 0x0005, DMI type 208, 10 bytes OEM-specific Type Header and Data: D0 0A 05 00 02 01 FE 00 0E 02

Handle 0x0006, DMI type 212, 18 bytes OEM-specific Type Header and Data: D4 12 06 00 70 00 71 00 00 10 2D 2E FF FF 00 00 00 00

Handle 0x0007, DMI type 212, 93 bytes OEM-specific Type Header and Data: D4 5D 07 00 70 00 71 00 00 46 7A 7B 51 00 65 F0 00 52 00 65 F0 01 53 00 65 F0 02 6E 00 4E F7 08 23 00 64 3F C0 9E 00 3E F8 02 9D 00 3E F8 00 A3 00 3A FC 01 A1 00 3A FC 00 6D 00 55 FE 01 55 00 55 FE 00 4A 01 54 FE 01 4B 01 54 FE 00 2D 00 4E E7 08 22 40 65 F0 04 FF FF 00 00 00 00

Handle 0x0008, DMI type 212, 18 bytes OEM-specific Type Header and Data: D4 12 08 00 70 00 71 00 00 00 00 00 FF FF 00 00 00 00

Handle 0x0009, DMI type 218, 17 bytes OEM-specific Type Header and Data: DA 11 09 00 2E 14 88 00 00 00 00 FF FF 00 00 00 00

Handle 0x000A, DMI type 221, 19 bytes OEM-specific Type Header and Data: DD 13 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Handle 0x000B, DMI type 222, 13 bytes OEM-specific Type Header and Data: DE 0D 0B 00 00 00 00 00 00 00 00 00 00

Handle 0x000C, DMI type 4, 40 bytes Processor Information Socket Designation: Socket AM2 Type: Central Processor Family: Athlon 64 Manufacturer: AMD ID: B1 0F 06 00 FF FB 8B 17 Signature: Family 15, Model 107, Stepping 1 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) HTT (Multi-threading) Version: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ Voltage: 1.3 V External Clock: 200 MHz Max Speed: 3700 MHz Current Speed: 2300 MHz Status: Populated, Enabled Upgrade: Socket 940 L1 Cache Handle: 0x000D L2 Cache Handle: 0x000E L3 Cache Handle: Not Provided Serial Number:
Asset Tag:
Part Number:
Core Count: 2 Core Enabled: 2 Thread Count: 2 Characteristics: 64-bit capable

Handle 0x000D, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Synchronous Installed SRAM Type: Synchronous Speed: Unknown Error Correction Type: Single-bit ECC System Type: Data Associativity: 4-way Set-associative

Handle 0x000E, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 1024 kB Maximum Size: 1024 kB Supported SRAM Types: Synchronous Installed SRAM Type: Synchronous Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 4-way Set-associative

Handle 0x000F, DMI type 9, 13 bytes System Slot Information Designation: PCI1 Type: 32-bit PCI Current Usage: Available Length: Short ID: 1 Characteristics: 5.0 V is provided PME signal is supported

Handle 0x0010, DMI type 9, 13 bytes System Slot Information Designation: PCI2 Type: 32-bit PCI Current Usage: In Use Length: Short ID: 2 Characteristics: 5.0 V is provided PME signal is supported

Handle 0x0011, DMI type 9, 13 bytes System Slot Information Designation: PCIEX16 Type: x16 PCI Express Current Usage: In Use Length: Short ID: 1 Characteristics: 5.0 V is provided PME signal is supported

Handle 0x0012, DMI type 9, 13 bytes System Slot Information Designation: PCIEX1_1 Type: x1 PCI Express Current Usage: Available Length: Short ID: 2 Characteristics: 5.0 V is provided PME signal is supported

Handle 0x0013, DMI type 13, 22 bytes BIOS Language Information Language Description Format: Long Installable Languages: 3 n|US|iso8859-1 n|US|iso8859-1 r|CA|iso8859-1 Currently Installed Language: n|US|iso8859-1

Handle 0x0014, DMI type 16, 15 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: None Maximum Capacity: 4 GB Error Information Handle: Not Provided Number Of Devices: 4

Handle 0x0015, DMI type 17, 27 bytes Memory Device Array Handle: 0x0014 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 1024 MB Form Factor: DIMM Set: None Locator: DIMM_1 Bank Locator: Not Specified Type: DDR2 Type Detail: None Speed: 667 MHz Manufacturer: AD00000000000000 Serial Number: 00001194 Asset Tag: 010736 Part Number: HYMP512U64CP8-Y5

Handle 0x0016, DMI type 17, 27 bytes Memory Device Array Handle: 0x0014 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 1024 MB Form Factor: DIMM Set: None Locator: DIMM_2 Bank Locator: Not Specified Type: DDR2 Type Detail: None Speed: 667 MHz Manufacturer: AD00000000000000 Serial Number: 00005196 Asset Tag: 010736 Part Number: HYMP512U64CP8-Y5

Handle 0x0017, DMI type 17, 27 bytes Memory Device Array Handle: 0x0014 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: No Module Installed Form Factor: DIMM Set: None Locator: DIMM_3 Bank Locator: Not Specified Type: Unknown Type Detail: None Speed: Unknown Manufacturer: None Serial Number: None Asset Tag: None Part Number: None

Handle 0x0018, DMI type 17, 27 bytes Memory Device Array Handle: 0x0014 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: No Module Installed Form Factor: DIMM Set: None Locator: DIMM_4 Bank Locator: Not Specified Type: Unknown Type Detail: None Speed: Unknown Manufacturer: None Serial Number: None Asset Tag: None Part Number: None

Handle 0x0019, DMI type 19, 15 bytes Memory Array Mapped Address Starting Address: 0x00000000000 Ending Address: 0x0007FFFFFFF Range Size: 2 GB Physical Array Handle: 0x0014 Partition Width: 1

Handle 0x001A, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x0003FFFFFFF Range Size: 1 GB Physical Device Handle: 0x0015 Memory Array Mapped Address Handle: 0x0019 Partition Row Position: 1

Handle 0x001B, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00040000000 Ending Address: 0x0007FFFFFFF Range Size: 1 GB Physical Device Handle: 0x0016 Memory Array Mapped Address Handle: 0x0019 Partition Row Position: 1

Handle 0x001C, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0017 Memory Array Mapped Address Handle: 0x0019 Partition Row Position: 1

Handle 0x001D, DMI type 20, 19 bytes Memory Device Mapped Address Starting Address: 0x00000000000 Ending Address: 0x000000003FF Range Size: 1 kB Physical Device Handle: 0x0018 Memory Array Mapped Address Handle: 0x0019 Partition Row Position: 1

Handle 0x001E, DMI type 32, 11 bytes System Boot Information Status: No errors detected

Handle 0x001F, DMI type 12, 5 bytes System Configuration Options Option 1:

Handle 0x0020, DMI type 127, 4 bytes End Of Table

Linux version 2.6.18-308.1.1.el5 (mockbuild@x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Fri Feb 17 16:47:13 EST 2012 BIOS-provided physical RAM map: BIOS-e820: 0000000000010000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007fee0000 (usable) BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS) BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data) BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved) BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f4c70 Memory for crash kernel (0x0 to 0x0) notwithin permissible range disabling kdump Using x86 segment limits to approximate NX protection On node 0 totalpages: 524000 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 294624 pages, LIFO batch:31 DMI 2.5 present. DMI: Dell Inc. Inspiron 531/0RY206, BIOS 1.0.3 06/15/2007 Using APIC driver default ACPI: RSDP (v002 DELL ) @ 0x000f7030 ACPI: XSDT (v001 DELL AS09 0x42302e31 AWRD 0x00000000) @ 0x7fee3100 ACPI: FADT (v003 DELL AS09 0x42302e31 AWRD 0x00000000) @ 0x7fee9380 ACPI: SLIC (v001 DELL AS09 0x42302e31 AWRD 0x00000000) @ 0x7fee9580 ACPI: SSDT (v001 DELL AS09 0x00000001 LTP 0x00000001) @ 0x7fee9740 ACPI: HPET (v001 DELL AS09 0x42302e31 AWRD 0x00000098) @ 0x7fee9a00 ACPI: MCFG (v001 DELL AS09 0x42302e31 AWRD 0x00000000) @ 0x7fee9a80 ACPI: MADT (v001 DELL AS09 0x42302e31 AWRD 0x00000000) @ 0x7fee94c0 ACPI: DSDT (v001 DELL AS09 0x00001000 MSFT 0x03000000) @ 0x00000000 ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:11 APIC version 16 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 15:11 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 I/O APIC #2 Version 17 at 0xFEC00000. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 80000000 (gap: 7ff00000:70100000) Detected 2310.470 MHz processor. Built 1 zonelists. Total pages: 524000 Kernel command line: ro root=LABEL=/ rhgb quiet pci=noacpi mapped APIC to ffffd000 (fee00000) mapped IOAPIC to ffffc000 (fec00000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0773000 soft=c0753000 PID hash table entries: 4096 (order: 12, 16384 bytes) spurious 8259A interrupt: IRQ7. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2070296k/2096000k available (2207k kernel code, 24436k reserved, 919k data, 232k init, 1178496k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. hpet0: at MMIO 0xfefff000 (virtual 0xf8800000), IRQs 2, 8, 31 hpet0: 3 32-bit timers, 25000000 Hz Using HPET for base-timer Calibrating delay loop (skipped), value calculated using timer frequency.. 4620.94 BogoMIPS (lpj=2310470) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000011f CPU: After vendor identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000011f CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 0(2) -> Core 0 CPU: After all inits, caps: 178bf3ff ebd3fbff 00000000 01000410 00002001 00000000 0000011f Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code ACPI: Core revision 20060707 ACPI: setting ELCR to 0ea0 (from 0ca0) CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 01 SMP alternatives: switching to SMP code Booting processor 1/1 eip 11000 CPU 1 irqstacks, hard=c0774000 soft=c0754000 Initializing CPU#1 Calibrating delay using timer specific routine.. 4621.01 BogoMIPS (lpj=2310505) CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000011f CPU: After vendor identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000011f CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU 1(2) -> Core 1 CPU: After all inits, caps: 178bf3ff ebd3fbff 00000000 01000410 00002001 00000000 0000011f Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 01 Total of 2 processors activated (9241.95 BogoMIPS). ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 Using local APIC timer interrupts. checking TSC synchronization across 2 CPUs: CPU#0 had 562 usecs TSC skew, fixed it up. CPU#1 had -562 usecs TSC skew, fixed it up. Brought up 2 CPUs sizeof(vma)=84 bytes sizeof(page)=32 bytes sizeof(inode)=340 bytes sizeof(dentry)=136 bytes sizeof(ext3inode)=492 bytes sizeof(buffer_head)=52 bytes sizeof(skbuff)=176 bytes migration_cost=153 checking if image is initramfs... it is Freeing initrd memory: 2559k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using MMCONFIG Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: No dock devices found. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: IRQ 8 override to level, low PCI: setting IRQ 8 as level-triggered pnp: PnP ACPI: found 10 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - 0000:00:04.0 PCI: Using IRQ router default [10de/03ea] at 0000:00:00.0 PCI->APIC IRQ transform: 0000:00:01.1[A] -> IRQ 10 PCI->APIC IRQ transform: 0000:00:02.0[A] -> IRQ 7 PCI->APIC IRQ transform: 0000:00:02.1[B] -> IRQ 11 PCI->APIC IRQ transform: 0000:00:05.0[B] -> IRQ 11 PCI->APIC IRQ transform: 0000:00:07.0[A] -> IRQ 5 PCI->APIC IRQ transform: 0000:00:08.0[A] -> IRQ 11 PCI->APIC IRQ transform: 0000:00:08.1[B] -> IRQ 10 PCI->APIC IRQ transform: 0000:01:09.0[A] -> IRQ 7 PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 7 NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default pnp: 00:01: ioport range 0x1000-0x107f could not be reserved pnp: 00:01: ioport range 0x1080-0x10ff has been reserved pnp: 00:01: ioport range 0x1400-0x147f has been reserved pnp: 00:01: ioport range 0x1480-0x14ff could not be reserved pnp: 00:01: ioport range 0x1800-0x187f has been reserved pnp: 00:01: ioport range 0x1880-0x18ff has been reserved pnp: 00:08: iomem range 0xf0000000-0xf3ffffff has been reserved pnp: 00:09: iomem range 0xcce00-0xcffff has been reserved pnp: 00:09: iomem range 0xf0000-0xf7fff could not be reserved pnp: 00:09: iomem range 0xf8000-0xfbfff could not be reserved pnp: 00:09: iomem range 0xfc000-0xfffff could not be reserved PCI: Bridge: 0000:00:04.0 IO window: b000-0000 MEM window: fde00000-00000000 PREFETCH window 0x00000000fdd00000-0x00000000fddfffff PCI: Bridge: 0000:00:09.0 IO window: a000-0000 MEM window: f8000000-00000000 PREFETCH window 0x00000000e0000000-0x00000000efffffff PCI: Bridge: 0000:00:0b.0 IO window: 9000-0000 MEM window: fdc00000-00000000 PREFETCH window 0x00000000fdb00000-0x00000000fdbfffff PCI: Setting latency timer of device 0000:00:04.0 to 64 PCI: Setting latency timer of device 0000:00:09.0 to 64 PCI: Setting latency timer of device 0000:00:0b.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) apm: disabled - APM is not SMP safe. audit: initializing netlink socket (disabled) type=2000 audit(1365796081.633:1): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API alg: No test for crc32c (crc32c-generic) ksign: Installing public key data Loading keyring

edaniszewski commented 10 years ago

I played around a bit more with CentOS on the AMD machine. The good news is that the AMD machine seems to be stable and not decaying as I use it.. The bad news is that when srtnmake is run, we get the error:

[radiotelescope@localhost srtnver3]$ ./srtnmake
Package libusb-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libusb-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libusb-1.0' found

which is peculiar because:

  1. On Fedora, which uses the same package manager, when I sudo yum install libusb-dev, srtn is able to locate libusb successfully
  2. I followed the suggestion given, to update PKG_CONFIG_PATH, which should have to happen since yum should take care of that.. and after doing so successfully and checking to see if the file that we need was at the path specified, the same error was returned.
[radiotelescope@localhost libusb-1.0.9]$ echo $PKG_CONFIG_PATH
/usr/local/lib/pkgconfig:

Its almost as if CentOS doesn't want libusb..

As a side note, I tried installing libusb from their website, in addition to trying with yum, and after (apparently) running ./configure make and sudo make install successfully, the same error persisted.

Bummer!

I'll probably take another crack at it in the morning. Time to take a break.

acencini commented 10 years ago

i found another AMD machine in my garage (well, two of them but only one is really functional)

it already has ubuntu amd64 on it and i'm putting gtk on there and libusb as well as the srtn sources (it is out in my garage hooked up to the satellite pulling everything down off a hardwired connection). i'm going to mess around with it some, and am also downloading centos as well just in case.

the libusb not found problem should be more solvable, but i'm going to try a few unbuntu voodoo tricks first. if you want me to bring said specimen in let me know.

acencini commented 10 years ago

was able to build srtnv3 on ubuntu 11.10 amd64

i don't have the dongle or the rotator controller so i suspect this is not huge news; however, everything runs fine in simulation mode (i disabled simulate fft as well just for giggles)

might see if i can get a virtual ubuntu intel instance set up on my machine here so i can look at the address space layout of the program in both places. i'll also give this a go with centos when it finishes downloading.

acencini commented 10 years ago

http://stackoverflow.com/questions/10157898/how-to-make-libusb-library-visible-to-another-program

edaniszewski commented 10 years ago

I can't remember exactly which command I used to update the PKG_CONFIG_PATH, but it looked similar to what was listed in the stack overflow question. I'll take another look at it tomorrow though-- thanks!

I should note-- before I went and installed CentOS, I installed Ubuntu 12.04 onto the AMD machine and that was working. Like you said, and after a bit of modification ( I think srtnmake needed to have gtk+-2.0 added to the gcc line) I got srtn to work when receiver and antenna were simulated. It also worked when receiver (dongle) was not simulated, and it seemed to be reading data from it consistent to how it was reading data before. I attempted unsimulating the antenna (using our rotator) and it got a buffer overflow. I changed the values in sport.c and plot.c that we changed before and it seemed to have the same effect, so the problem didn't seem mitigated. This was all done with the last option in srtnmake (compile for dongle + c-coded FFT)

After that somewhat unsurprising result, I thought I would try out the option to compile for dongle + and FFT. As outlined in the README,

2] amd FFT

The following files library files may be required (and are included)
if the ones on the PC are not compatible:

libacml.so
libgfortran.a

So I moved the two to their appropriate places, but when I tried to compile, I kept getting errors about how something like /usr/bin/ld -lacml could not be found (I'm pulling from memory, so this may be a little off), so I spent some time looking how to get acml linked properly and installed what I think was the acml library from http://developer.amd.com/tools-and-sdks/cpu-development/amd-core-math-library-acml/acml-downloads-resources/ I spent some time going through that and trying to get it to work, but it didn't seem to do much, so I was stuck at that point and not really able to test out the hardware FFT..

Before THAT, I did the same thing, looking at Ubuntu 12.04, except on the Intel machine because for some reason I thought it was weird that there are compiling options for both AMD and Intel, so both should work? Needless to say, the compile for dongle + c-coded FFT option didn't work and gave the same results we were getting before, and when I tried to compile for dongle + intel FFT, I followed the suggestion in the README:

3] Intel FFT

Obtain fftw from www.fftw.org download fftw-3.3.3.tar.gz
and install using float precision

and after a bit of struggling, it didn't seem to work either.

I should note that with all the combinations of things that I did, I may have gotten the specific results mixed up in this post, but the end result of not working was consistent in all my trials. There is also the possibility that I may have done a few things incorrectly (particularly when it came to downloading from the web and installing myself versus having a package be installed by the package manager) so it could just be that I did something wrong.

I didn't have any problems with the AMD machine either this time which is a little weird since it was giving us a little grief during class, so I'm not sure what changed.. the connections to the hard drive seemed a little loose, so maybe I just got the cables in at a better angle or something?

Sad results, but tomorrow is a new day and with your suggestions and a few ideas I've had, I might be able to make a little more progress tomorrow..

edaniszewski commented 10 years ago

Also, just to have them somewhere, these are some links that I found useful, and the problems that prompted them:

This will allow you to give your user account permission to sudo.

for good measure, here's the fftw site: http://fftw.org

acencini commented 10 years ago

hurrrr

here is the problem with libusb... centos and its evil cousins ship with libusb-0.1. doing yum install libusb-devel will put that on the machine

instead, yum install libusb1-devel

and all will be so much better

to be safe, use a completely clean and unmodified version of newsrtnsource_ver3 - after installing gtk and libusb1 i ran a total clean ./srtnmake and it built flawlessly. my virtual centos instance (on my mac virtualbox) is not currently set up with a GUI display, but i assume this should all work

granted, who knows what comes after we move that rock aside - but this should allow you to build clean free and happy.

On Tue, Apr 1, 2014 at 11:30 PM, Erick Daniszewski <notifications@github.com

wrote:

Also, just to have them somewhere, these are some links that I found useful, and the problems that prompted them:

This will allow you to give your user account permission to sudo.

for good measure, here's the fftw site: http://fftw.org

-

the README says to get a specific version of fftw, you can do this from http://fftw.org/download.html and click the link to browse the ftp site, which will give you what appears to be all the old versions too! Neat!

I think I may have posted this elsewhere, but maybe not.. to make a USB bootable on Mac OS, : http://borgstrom.ca/2010/10/14/os-x-bootable-usb.html

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39285635 .

acencini commented 10 years ago

i was able to get the sucker to run, however i ran into the font problem as well

in disp.c on line 485 there is a call to gdk_font_load (gdk_fontset_load is the preferred modern incantation); the txt buffer contains the font gettext nastiness. since this works elsewhere, i am inclined to believe that this is a weirdness of how gnome/X/gtk is set up by centos. if i have time later, i will investigate more, but do not consider this blocking as we can always rely on the debug output and if it does not crap out on a buffer overrun with the non-simulated rotator, then we can see if it controls the rotator by setting the azel or trying to stow the dish.

gdk_font_load returns NULL which gets tossed into every call that writes text to the display, thus the assertion errors. annoying. if we can get gdk_font_load to load a damn font, that will be fixed. we inch closer.

On Wed, Apr 2, 2014 at 12:32 AM, Andrew Cencini acencini@gmail.com wrote:

hurrrr

here is the problem with libusb... centos and its evil cousins ship with libusb-0.1. doing yum install libusb-devel will put that on the machine

instead, yum install libusb1-devel

and all will be so much better

to be safe, use a completely clean and unmodified version of newsrtnsource_ver3 - after installing gtk and libusb1 i ran a total clean ./srtnmake and it built flawlessly. my virtual centos instance (on my mac virtualbox) is not currently set up with a GUI display, but i assume this should all work

granted, who knows what comes after we move that rock aside - but this should allow you to build clean free and happy.

On Tue, Apr 1, 2014 at 11:30 PM, Erick Daniszewski < notifications@github.com> wrote:

Also, just to have them somewhere, these are some links that I found useful, and the problems that prompted them:

This will allow you to give your user account permission to sudo.

for good measure, here's the fftw site: http://fftw.org

-

the README says to get a specific version of fftw, you can do this from http://fftw.org/download.html and click the link to browse the ftp site, which will give you what appears to be all the old versions too! Neat!

I think I may have posted this elsewhere, but maybe not.. to make a USB bootable on Mac OS, : http://borgstrom.ca/2010/10/14/os-x-bootable-usb.html

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39285635 .

edaniszewski commented 10 years ago

I did yum install libusb1-devel and that took care of the libusb problem! Horay!

Also per your suggestion, after doing this I used a clean version of srtnver3 completely unmodified, and it worked (gcc didn't even throw any warnings, though that could just be a CentOS thing) which is exciting.

For simulated antenna motion and simulated dongle, it worked as expected and all the text was there and it looked good.

For non-simulated dongle and simulated antenna motion, it looked good too, and looked like it was picking up reasonable data from the dongle.

For non-simulated dongle and non-simulated antenna motion, less good news. I ran into the same error this all started with -- or presumably so, since the GUI looked the same as it did on Ubuntu when we were getting the large min values which made things weird. I didn't check the values yet but its probably likely to be the same problem. The good part about all this (maybe?) is that there was no crash due to buffer overflow. It just spit out weird numbers or NaNs to the GUI..

edaniszewski commented 10 years ago

I didn't experience any of the font problems though.. which I guess is a good thing, but odd since you ran into that problem..

I'm going to try a clean build of srtnver2 now to see if that does anything..

edaniszewski commented 10 years ago

ver2 has the same problem.. doesn't throw any warnings or errors on compile, and seems to work fine until antenna motion is not simulated, then it prints out LARGE numbers to GUI and the integral is NaN. In the top corner it also says "waiting on antenna xx" where xx is a count up ( I waited until it reached 20 until exiting, I don't thing it should take that long to communicate with the controller)

acencini commented 10 years ago

by any chance does it cause the rotator to do anything? does clicking stow make happy? setting azel to 123 through the UI

glad fonts are working for you. i have been wasting enormous amounts of time this morning learning about how fonts work in centos. won't get those hours of my life back. that said, it appears the fonts specified in the code are not installed with centos or the X distro i am using, so that probably makes sense - i'm just trying to cook up a proper font string to reflect my actual fonts to see if that will work

On Wed, Apr 2, 2014 at 9:02 AM, Erick Daniszewski notifications@github.comwrote:

I didn't experience any of the font problems though.. which I guess is a good thing, but odd since you ran into that problem..

I'm going to try a clean build of srtnver2 now to see if that does anything..

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39326825 .

acencini commented 10 years ago

nice work! we are getting close

On Wed, Apr 2, 2014 at 9:09 AM, Andrew Cencini acencini@gmail.com wrote:

by any chance does it cause the rotator to do anything? does clicking stow make happy? setting azel to 123 through the UI

glad fonts are working for you. i have been wasting enormous amounts of time this morning learning about how fonts work in centos. won't get those hours of my life back. that said, it appears the fonts specified in the code are not installed with centos or the X distro i am using, so that probably makes sense - i'm just trying to cook up a proper font string to reflect my actual fonts to see if that will work

On Wed, Apr 2, 2014 at 9:02 AM, Erick Daniszewski < notifications@github.com> wrote:

I didn't experience any of the font problems though.. which I guess is a good thing, but odd since you ran into that problem..

I'm going to try a clean build of srtnver2 now to see if that does anything..

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39326825 .

acencini commented 10 years ago

AHA i figured out how we can fix the font problem if we ever need to :)

xlsfonts lists all the fonts available to us...

i picked something close in the misc-fixed font family that was given to me and fonts displayed just fine on my centos instance

On Wed, Apr 2, 2014 at 9:10 AM, Andrew Cencini acencini@gmail.com wrote:

nice work! we are getting close

On Wed, Apr 2, 2014 at 9:09 AM, Andrew Cencini acencini@gmail.com wrote:

by any chance does it cause the rotator to do anything? does clicking stow make happy? setting azel to 123 through the UI

glad fonts are working for you. i have been wasting enormous amounts of time this morning learning about how fonts work in centos. won't get those hours of my life back. that said, it appears the fonts specified in the code are not installed with centos or the X distro i am using, so that probably makes sense - i'm just trying to cook up a proper font string to reflect my actual fonts to see if that will work

On Wed, Apr 2, 2014 at 9:02 AM, Erick Daniszewski < notifications@github.com> wrote:

I didn't experience any of the font problems though.. which I guess is a good thing, but odd since you ran into that problem..

I'm going to try a clean build of srtnver2 now to see if that does anything..

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39326825 .

acencini commented 10 years ago

for the antenna movement / wait issue, i am assuming /dev/ttyUSB0 exists now since it would whine otherwise

it might be good to enable debug mode on that to see what it is sending - not your debug, but the stock debug

just to be sure - the usb for the rotator is >not< plugged into a USB3.0 port in the back (so it should be in a USB2.0 port). the 3.0 ports are squirrelly.

i'll be in in a little bit - might sit down and see if we can see what's happening there. i think we are very close.

On Wed, Apr 2, 2014 at 9:39 AM, Andrew Cencini acencini@gmail.com wrote:

AHA i figured out how we can fix the font problem if we ever need to :)

xlsfonts lists all the fonts available to us...

i picked something close in the misc-fixed font family that was given to me and fonts displayed just fine on my centos instance

On Wed, Apr 2, 2014 at 9:10 AM, Andrew Cencini acencini@gmail.com wrote:

nice work! we are getting close

On Wed, Apr 2, 2014 at 9:09 AM, Andrew Cencini acencini@gmail.comwrote:

by any chance does it cause the rotator to do anything? does clicking stow make happy? setting azel to 123 through the UI

glad fonts are working for you. i have been wasting enormous amounts of time this morning learning about how fonts work in centos. won't get those hours of my life back. that said, it appears the fonts specified in the code are not installed with centos or the X distro i am using, so that probably makes sense - i'm just trying to cook up a proper font string to reflect my actual fonts to see if that will work

On Wed, Apr 2, 2014 at 9:02 AM, Erick Daniszewski < notifications@github.com> wrote:

I didn't experience any of the font problems though.. which I guess is a good thing, but odd since you ran into that problem..

I'm going to try a clean build of srtnver2 now to see if that does anything..

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39326825 .

edaniszewski commented 10 years ago

Right now, it causes the rotator to move back to stow when its initially run, if the rotator is not already there, same as it did on Ubuntu, but I can't seem to make it do anything else with the rotator, but at the very least that means its communicating with it successfully.. playing around with the buttons and inputting values via the UI didn't seem to help ):

I made sure the dongle and controller weren't in the USB3.0 ports since I knew that was a problem from yesterday, so thats not the problem.

I ran srtn in gdb and set a breakpoint in plot.c Repaint() at the same place we were getting the weird min values and printed the min values, and it looks like its the same problem. min = 9.9999999999999997e+98 yikes!

edaniszewski commented 10 years ago

Looking at gdb in plot.c, we've only looked at the value of min and max, pretty much, before, but this time I looked into the values of spec[i], bspec[i], and aavspec[i], which are used to set the value of c, then c is used for the inequality comparisons to set max and min. What I found was that when the rotator was not simulated, the values in these arrays were either 1's or 0's. When I ran srtn with rotator motion simulated, I looked at some of the values and they were not all 1's and 0's... so it seems the reason that min and max are acting weird is because the values in spec[] and its cousins are not set properly. I'll spend some time after lunch hunting for where they get set and to see if I can uncover why they are getting set incorrectly.

edaniszewski commented 10 years ago

From a quick search in Sublime, it seems that likely locations will be either in main.c or vspectra.c ( or whichever one of its variants are being used in our compile scheme.. for software fft, I think its vspectra_four.c)

edaniszewski commented 10 years ago

What I've found so far: When rotator simulation is on, vspectra_four.c is used (and calls Four(), from four.c, which I think might be the software fft?) and the values of vspec[i] are changed somewhere around line 113 in the clean build. spec[i] is changed somewhere around line 137. So thats good, and the values agree with what I found the values to be when I printed spec[i] within plot.c in Repaint(). Cool!

Weird part: I put breakpoints in the same places, then ran it without simulating the rotator and none of the breakpoints were reached. i.e., without simulation, vspectra_four is not called... that could explain why none of the values in spec[i] appeared to have been changed when I printed it from Repaint() earlier..

Time for more digging..

edaniszewski commented 10 years ago

Based on my search for where vspectra() is called, it looks to only be called in one place -- cool! In main.c:

if (!d1.slew)
            vspectra();

so , it will only be called if the antenna is not slewing. Let's see where d1.slew is set. Again, only a limited amount of places: In main.c:

if (d1.slew)
            d1.slew = 0;

which is contained within

if (d1.docal) {
            if (d1.bsw) {
                d1.bsw = 0;
                d1.azoff = 0.0;
            }
            if (d1.scan) {
                d1.scan = 0;
                d1.eloff = d1.azoff = 0.0;
            }
            if (d1.slew)
                d1.slew = 0;
            if (d1.docal == 1)
                cal(0);
            d1.docal = 2;
            cal(1);
            if (d1.integ >= NCAL) {
                cal(2);
                d1.docal = 0;
            }
        }

and its also changed within sport.c. At the top, it is set to 0, d1.slew = 0; and later ( ~line 140) (approximate line numbers because my version that I am reading off of has some added comments and such that are not present in the clean build):

    if ((fabs(d1.aznow - d1.azcmd) > 1.5 || fabs(d1.elnow - d1.elcmd) > 1.5) && d1.track != -1) {
        if ((fabs(d1.aznow - d1.azcmd) > 1.5 || fabs(d1.elnow - d1.elcmd) > 1.5) && d1.stow != -1) {
            d1.slew = 1;
            sprintf(txt, "ant slewing");
...

and ( ~line 200)

if (fabs(d1.aznow - d1.azcmd) > 1.0 || fabs(d1.elnow - d1.elcmd) > 1.0) {
                if (d1.printout)
                   // printf("waiting on antenna cmd %3.0f %3.0f now %3.0f %3.0f kk %d\n", d1.azcmd, d1.elcmd,
                        //   d1.aznow, d1.elnow, kk);
                sprintf(txt, "waiting on antenna %d ", kk);
                d1.slew = 1;
...

Since this is really the only place it gets set to 1, it may be likely that something within here is being weird.. I'll leave this here for now and continue searching! Hopefully this isn't a wild goose chase. :bird:

acencini commented 10 years ago

um, i think we can close this one and declare it miller time

On Wed, Apr 2, 2014 at 2:01 PM, Erick Daniszewski notifications@github.comwrote:

Based on my search for where vspectra() is called, it looks to only be called in one place -- cool! In main.c:

if (!d1.slew) vspectra();

so , it will only be called if the antenna is not slewing. Let's see where d1.slew is set. Again, only a limited amount of places: In main.c:

if (d1.slew) d1.slew = 0;

which is contained within

if (d1.docal) { if (d1.bsw) { d1.bsw = 0; d1.azoff = 0.0; } if (d1.scan) { d1.scan = 0; d1.eloff = d1.azoff = 0.0; } if (d1.slew) d1.slew = 0; if (d1.docal == 1) cal(0); d1.docal = 2; cal(1); if (d1.integ >= NCAL) { cal(2); d1.docal = 0; } }

and its also changed within sport.c. At the top, it is set to 0, d1.slew = 0; and later ( ~line 140) (approximate line numbers because my version that I am reading off of has some added comments and such that are not present in the clean build):

if ((fabs(d1.aznow - d1.azcmd) > 1.5 || fabs(d1.elnow - d1.elcmd) > 1.5) && d1.track != -1) {

    if ((fabs(d1.aznow - d1.azcmd) > 1.5 || fabs(d1.elnow - d1.elcmd) > 1.5) && d1.stow != -1) {
        d1.slew = 1;
        sprintf(txt, "ant slewing");...

and ( ~line 200)

if (fabs(d1.aznow - d1.azcmd) > 1.0 || fabs(d1.elnow - d1.elcmd) > 1.0) { if (d1.printout) // printf("waiting on antenna cmd %3.0f %3.0f now %3.0f %3.0f kk %d\n", d1.azcmd, d1.elcmd, // d1.aznow, d1.elnow, kk); sprintf(txt, "waiting on antenna %d ", kk); d1.slew = 1;...

Since this is really the only place it gets set to 1, it may be likely that something within here is being weird.. I'll leave this here for now and continue searching! Hopefully this isn't a wild goose chase. [image: :bird:]

Reply to this email directly or view it on GitHubhttps://github.com/BenningtonCS/Telescope-2014/issues/67#issuecomment-39362828 .

acencini commented 10 years ago

image

edaniszewski commented 10 years ago

the champagne of beers!