Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

donate to eham
   Home   Help Search  
Pages: [1]   Go Down
  Print  
Author Topic: Want deep info on packet AX25  (Read 8883 times)
KG6QGF
Member

Posts: 8




Ignore
« on: September 21, 2017, 10:36:30 AM »

THis may be a dumb idea but....or maybe I am late to the party and this is old...

I have started several times over the years to begin studying packet AX25 and deciphering, but keep getting distracted;  knowing time is a commodity, and without wasting time looking through useless documentation, is there a concise document (that uses short, easily understandable descriptions and does not try to impress me with paragraphs of uselessness) that outlines APRS packet construction at a byte level and details how packet is constructed (inertial hops, call signs, packet type, etc)?  Something I could use as a guide for Arduino programming?  I presume at some layer the data type is embedded (such as location$, weather$, perhaps email$ or txt$) and an arduino could be connect to a KISS TNC and set to look for my call sign and txt header, then display the txt or email content?

Also, is there any concept of taking igate data and rebroadcasting back out over the air in by location and have a simple one-direction channel that spews Igate data that could be used to draw map on a mobile device?  NOT CELL CONNECTED, rather VHF/UHF connected?  for example, I would sent APRS tx data out on 144.390 and could rx on (I have not checked band plan so humor me) 435.050 and see all received Igate data/traffic in my region including my own?
Logged
W1VT
Member

Posts: 2485




Ignore
« Reply #1 on: September 21, 2017, 04:22:26 PM »

https://www.tapr.org/pub_ax25.html
Link layer protocol
Logged
KG6QGF
Member

Posts: 8




Ignore
« Reply #2 on: September 26, 2017, 12:14:13 PM »

I am going to write is more as rhetorical to myself rather than a discussion, but feel free to jump in and beat me up...And I am sure I will not make any new friends with this thread.

What am I ultimately looking at?  Since smart phones and internet are both mainstream now, and given that voice phone calls are dwarfed by txt, email and internet usage...where are we with respect to hams being able to seamlessly utilize these data-concentric functions, whether it be packet or Hamnet or other.  Why are current Ham radio offerings and products "voice concentric" rather than "data concentric"?  The three primary reasons for 2017 Ham radio (In my humble opinion) are as follows;  Community contributions, emergency/disaster communication and backbone redundancy, international good will..I think the days of Hams leading radio and technology experimentation and development are long gone (I have a single piece of test equipment here at work that costs $650,000-how do hams compete with this?) .  It is best able to perform second task by being capable and seamless to use, and Hams are already using it day to day to ensure it will work when a disaster actually hits.  Also, I don't expect packet or Hamnet replace the smartphone or internet, or be as fast or efficient, rather a backup when bad things happen.

So I wanted to see this first hand, where we are today with respect to this concept.  I built a KISS TNC using code from Mobilinkd, more than anything so I could study raw data from APRS.  I have also been looking at other "autonomous" solutions for APRS and maybe I am just not understanding it, but I think vendors are missing the mark;  this sentence from Mobilinkd says it all...BT Connection Tracking – When enabled, the TNC tracks the state of the Bluetooth connection and discards any packets received while the Bluetooth connection is down.  Why would it do that???  Seems to be exactly time when it SHOULD be receiving, digipeating and storing relevant data!  If I get a message from another Ham, why it not store it and forward to me when I reconnect?  Why should my map not be up to date over the air while I am off-line?  WHy should I have to link up for 30 minutes to get in sync?  Why should I have to leave my home computer connected and on to do such a menial task?  Imagine if your smartphone did this; You can only be messaged or emailed if phone is on and you are looking at it???

As for backbone of APRS, I am not really getting it either.  Should Igate not be 2-way?  Should I not be able to send some sort of "fetch" or "pull" packet request that goes to Igate, if it has any relevant info for my call sign, why it not forward to me when I send "fetch" request that comes out over the air?  Messages, email, current beacon and weather locations on my track list, text messages?

I think that SainSOnic almost had it correct with AP510 APRS.  THey only missed the part about off-line packet handling and storage.  A compact VHF transmitter that handles digipeating and stores beacons, updates each location, stores messages and then dumps to smartphone or tablet when it reconnects bluetooth seems correct.


Lastly, while antiquating myself with my packet radio and TNCs, I connected to local BBS in San Jose.   I also did some reading on re purposed Linksys WRT54G as broadband Hamnet-what I am finding in both VHF packet and 2.xx ghz and 5.xx ghz is a complete lack of connectivity to internet!  Or perhaps what appears to be intentional blocking of connectivity.  I understand the needs to keep all traffic un-encrypted or open;  I also understand that a licence holder must initiate all traffic both ways, and must not be commercial or pornographic in any way.   However, this means that in a disaster event, the ability to get information from the "information super highway" is non-existent!  consider this;  I want to simple searches for "sources of clean water" , "closest shelters", "food handout locations", etc.  Also, simple communications to relative in another state "we are OK, will be in contact soon" or "had to evac to next city"; a BBS is not going to help me much if it has no gateway.  Not to mention the sheer difficulty to find and set up TNC, download very poor (IMHO) versions of APRS software, find local channels used for Packet, only to discover that the resource connects to nothing-imagine trying to do this days before a hurricane.  I guess one might argue that voice communications could perform tasks above, but imagine the volume of people that might need information and communication during a big disaster-does it not make more since for this to be automated and data-concentric?  ALso, a Ham should be able to "pull" or "fetch" data or emails, information or texts from WWW...In that fashion they are responsible for content.  It should be easy and seamless for a Ham to reach information and WWW.

Again, this is just my personal ramblings to myself-feel free to tell me I am wrong and how.  Or that I am uninformed and these items do exist.

Logged
KB4QAA
Member

Posts: 3256




Ignore
« Reply #3 on: October 05, 2017, 09:15:54 AM »

Regarding connecting to the internet.    
-Amateur radio is for personal communications and is NOT to be use when other FCC authorized services are available and more appropriate.
-AR is not to be used for commercial purposes.   Much of the traffic on the internet is commercial.

Hence, using AR as an extension of the internet is not appropriate.
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

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