Meadville Space Center
Welcome, Guest. Please login or register.
June 07, 2020, 05:00:46 AM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  AGC interfacing
« previous next »
Pages: [1] 2 Print
Author Topic: AGC interfacing  (Read 4328 times)
Hitman458
Jr. Member
**
Posts: 8


View Profile
« on: February 11, 2016, 01:01:52 PM »

Hello guys,

I have some questions about how your NASSP implementation of yaAGC works.

Ron Burkey (the creator of yaAGC) told me that you were using a modified version of yaAGC.
In fact, original yaAGC uses TCP/IP socket to exchange IO channel data between the virtual machine and the DSKY.
He told me that you don't use TCP/IP socket (probably because of time wrap issues).

Is there a way to get the original TCP/IP socket implementation working in NASSP ?

If you wonder why I'm asking this, it is because I have an AGC at home and I want to connect it to NASSP. I already did with the original yaAGC and it works... but I'd like to use it with NASSP.

If there is no way to turn on the TCP/IP socket in NASSP, I just need to add a serial com port implementation in NASSP's source code.
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #1 on: February 12, 2016, 08:03:04 AM »

We pass the data directly because waiting on TCP would mean paying an unacceptable framerate penalty. I'm almost certain the TCP interface to yaAGC has been removed from the code, and even if you were able to turn TCP on again I can almost guarantee the result would not be able to run in real time. You would almost certainly have to make some kind of direct digital interface. Serial MIGHT be fast enough at 115k, too much slower and you're going to lose. (HBR telemetry alone is 51.2k)
Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #2 on: February 12, 2016, 05:34:27 PM »

Thank you for your answer.

OK, I understand the problem of the baud rate. That's sad Sad
However, I use a RS232 serial port emulated over USB, but I don't know if the driver respects the real baud rate or runs as fast as the USB can (I didn't test this).

I can get my hardware working as a simple man machine interface and only filter and keep DISKEY relevant channels : The keyboard, the 7 segments displays and the alarm panel. It should work, the bandwidth is very low.

Edit : I mean, the AGC still runs on the computer, and the computers filters the channels and only send relevant data on RS232
« Last Edit: February 12, 2016, 05:36:54 PM by Hitman458 » Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #3 on: February 12, 2016, 06:52:29 PM »

Ah, when you said you had "an AGC at home" I thought you meant a processor. A DSKY will fit in either TCP or serial just fine, there's nothing timing-dependent in it. If you just want you could use an unmodified NASSP by writing a program that interprets the downtelemetry datastream (available by TCP) and extracts the DSKY state, feeds it to your physical DSKY, and translates your DSKY button presses into uplink commands. If you want it to work more directly you'd have to hack in some interface of your own.
Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #4 on: February 13, 2016, 05:21:29 AM »

That's probably a good alternative. I have to look at the telemetry datastream to see how it looks like.

In fact, my DSKY is still in development (the hardware is finished but I'm still working on the microcontrollers firmware).

At first, I had built the DSKY only. It was not able to run an AGC but able to be interfaced with yaAGC as a physical interface.

Now I'm working on an embedded AGC virtual machine running inside a microcontroller to make a standalone AGC.
With the informations you give me, I think I won't be able to use this embedded AGC virtual machine with NASSP but I still can only use the DSKY as a physical interface.

The final step of my project is to make an AGC processor inside a FPGA (it's like a hard wired logic). But, I first need to write the virtual machine in order to understand exactly how the AGC works.

I find it sad to build something that is just able to continuously displays hours... and wanted to have something more interesting and useful with NASSP.

I had written a software acting like a bridge between the LAN (yaAGC) and the serial port. This bridge filters IO channels and translate Ron Burkey's protocol to a more efficient protocol for the microcontrollers.
So I "just" need to write another kind of bridge using the telemetry stream and translate the data.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #5 on: February 13, 2016, 07:30:30 AM »

I find it sad to build something that is just able to continuously displays hours...

That's what I'm always thinking when I see a DSKY-building project. So I'm excited how your project will turn out.  Thumbs Up
Logged
dseagrav
Moderator
Hero Member
****
Posts: 1118


View Profile
« Reply #6 on: February 13, 2016, 10:14:26 AM »

Oh, you -could- build an external agc processor, you'd just have to build some kind of direct interface to pass the data to and from it with a useful framerate. Time acceleration might not be workable, but you could absolutely work in real time.
Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #7 on: March 05, 2016, 06:38:57 AM »

I looked the telemetry, and I'm a bit disappointed about the lack of interactivity. I'm thinking about using a more direct way to send IO channels data to my DSKY.

I could download NASSP source code and compile it successfully. Now, I must hack the code and find an entry point in it. I need a bit of help as I don't know how NASSP works.

Ron Burkey's developer info says to hack ChannelInput, ChannelOutput and ChannelRoutine.

ChannelOutput :
I can add here the code to send data to the physical DSKY :
Code:
void ChannelOutput (agc_t * State, int Channel, int Value)
{

  // Some output channels have purposes within the CPU, so we have to
  // account for those separately.
  if (Channel == 7)
    {
      State->InputChannel[7] = State->OutputChannel7 = (Value & 0160);
      return;
    }
  // Most output channels are simply transmitted to clients representing
  // hardware simulations.

  ApolloGuidance *agc;

  agc = (ApolloGuidance *) State->agc_clientdata;
  agc->SetOutputChannel(Channel, Value);
}


ChannelInput :
Code:
//
// Do nothing here. We'll process input seperately.
//

int ChannelInput (agc_t *State)

{
return 0;
}
OK, so how it works ? Is this function still called and yaAGC pooling for data reception ?

ChannelRoutine :
I don't know if I need to add something here :
Code:
void ChannelRoutine (agc_t *State)

{
}

yaAGC seems to be present in several modules (LEM, Saturn1b, Saturn5NASP). Is there only one instance of yaAGC running at a time ?


Edit : I can write my own answer :

I'm going to rewrite Ron Burkey's socket implementation for these functions.
I will add a filter in ChannelOutput in order to disguard non DSKY channels (because of the limited baud rate).
yaAGC is still pooling ChannelInput, so it's ok.
ChannelRoutine is used to instantiate the TCP/IP Server and handle new clients connections.

With some hope, I just need to copy the original yaAGC source code and past it in NASSP.
And with some luck, there will be no side effect.

If I doesn't work, I can find a way to directly write to the serial port of the computer instead of using the TCP/IP server.


« Last Edit: March 05, 2016, 07:55:36 AM by Hitman458 » Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #8 on: March 05, 2016, 01:01:07 PM »

It works Happy

Here is 2 quick&dirties videos showing the AGC working with NASSP :

PRE-LAUNCH :
V16N65E to monitor time before lift off
V35E to test the display
V37E01E run program 01
https://www.dropbox.com/s/pz7sb0kw037x8by/1%20-%20PRE-LAUNCH.mp4?dl=0

LAUNCH :
https://www.dropbox.com/s/8t1obksdnmp2p1f/2%20-%20LAUNCH.mp4?dl=0

Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #9 on: March 06, 2016, 07:13:03 AM »

Very impressive work, now you have a DSKY device that will be able to do much, much more than just displaying the CMC clock.

I don't understand too much about this part of the NASSP code, how much did you have to change to make it work? Would it be feasible to kind of support a device like this as part of NASSP?
Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #10 on: March 06, 2016, 06:28:42 PM »

The fastest way for me was to get back the original yaAGC source code from Ron Burkey.

I put back a dozen functions that directly come from yaAGC. I added them in apolloguidance.cpp and agc_utilities.cpp.

I modified Ron's functions called ChannelInput and ChannelOutput to eliminate possible side effect and just keep things that are used only for the DSKY.

For my first attempt, I had noticed a latency because of the network. Orbiter was running on my laptop and my DSKY was connected to another computer. There was a visible delay in the display and COMP ACTY doesn't light as expected.
For my second attempt. Orbiter and the DSKY were running on the same computer and there was no network latency. No delay in the display, and COMP ACTY lights as expected.

So, on this observation I'm not sure if this is a good idea to keep the TCP/IP Socket or to directly write to the serial port.
I think that there is not such latency with the network for people who are building Flight Simulator cockpits.

Here is a better video I have just uploaded on youtube : https://www.youtube.com/watch?v=ecZQtStWviY

Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #11 on: September 15, 2017, 02:17:26 PM »

Hi everybody,

I wake up my topic. In fact, I'm still working on this project and have an other question.

I did a lof of changes in my DSKY : I've added a FPGA, and I'm now running a hardware AGC on it (not finished yet).

I wanted to make a new video/demo showing my new DSKY running with Apollo 11 launch.

Is there a way to setup the Virtual AGC and run it with the Apollo 11 scenario ?

Apollo 7 is the only scnerario where you can use the Virtual AGC, right ?


Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #12 on: September 15, 2017, 02:52:09 PM »

A lot more than only Apollo 7 is already working. In the current NASSP version for Orbiter 2016, Apollo 7 is actually the only launch scenario that is broken due to a terrain issue at that launchpad. There are functional launch scenarios for all manned Apollo missions in NASSP. For Apollo 11 it will depend on the version you are using, the NASSP 7.0 release for Orbiter 2010 or the NASSP 8.0 Alpha version for Orbiter 2016.

In the NASSP 7.0 release version there is a very functional Apollo 11 launch scenario under "Scenarios/Project Apollo - NASSP/Broken Scenarios/Virtual AGC/". NASSP 7.0 was only properly supporting Apollo 7 and 8, so this scenario isn't "advertised" as working, but it's up-to-date and has a fully configured Virtual AGC.

In the NASSP 8.0 Alpha version there are two Apollo 11 launch scenarios in the main scenario folder under "Scenarios/Project Apollo - NASSP". Any of the two will work for your purpose.

Logged
Hitman458
Jr. Member
**
Posts: 8


View Profile
« Reply #13 on: September 15, 2017, 03:45:52 PM »

Great, Thank you for your answer indy91. I was not sure about the differences between all these versions. I'm running Orbiter 2010 / NASSP V7.0 beta.

It seems to work Happy Apollo 11 with a physical DSKY Happy I hope I can make a nice video to share with you.



Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #14 on: September 15, 2017, 03:58:13 PM »

Great, Thank you for your answer indy91. I was not sure about the differences between all these versions. I'm running Orbiter 2010 / NASSP V7.0 beta.

It seems to work Happy Apollo 11 with a physical DSKY Happy I hope I can make a nice video to share with you.

I'm looking forward to watching your video! I enjoyed your last one as well. Also, it's not NASSP 7.0 Beta anymore. As of February this year, NASSP 7.0 is out of the beta stage and had a full release. So if you are not using the release version yet, here the link: https://github.com/dseagrav/NASSP/releases/download/NASSP-V7.0-Release-master-372/Project-Apollo-NASSP-V7.0.zip That's the same as linked on the NASSP website.
« Last Edit: September 15, 2017, 04:03:59 PM by indy91 » Logged
Pages: [1] 2 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!